タグ

ブックマーク / yakst.com (86)

  • インシデント指揮官トレーニングの手引き | Yakst

    [SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。

  • ロギングにおける十戒 | Yakst

    どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ

    ロギングにおける十戒 | Yakst
  • 「なんにもしない」スクリプトを書く: 段階的な自動化を進めるために | Yakst

    [SRE]原文 Do-nothing scripting: the key to gradual automation – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-07-15 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1724日前 Twitterで報告済み 編集 どんな運用チームにも、まだ自動化するところまで手が回っていない手作業があるものです。 トイル (toil) が完全に無くなることは決してありません。 成長企業のチームに非常にありがちなのが、インフラの変更手続きやユーザーアカウントのプロビジョニングが、最大のトイル源となっているケースです。 後者の例について手順の一部を書き出してみると、たとえば以下のようになるでしょう: ユーザーのSSHキーペアを作成する 公開鍵をGit

    mapk0y
    mapk0y 2019/09/05
  • MySQLのコネクションハンドリングとスケーリング | Yakst

    MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関

    mapk0y
    mapk0y 2019/05/20
  • MySQLの準同期レプリケーションに関する質問への回答と詳細 | Yakst

    MySQLの準同期・ロスレス準同期レプリケーションの仕組みを解説し、同機能についてのよくある誤解やメリットについて説明します。 最近、メールで「MySQL Lossless Semi-Synchronous Replication」について質問されることがありました。この質問への答えは多くの人にとって有益であると考えたため、回答をこのブログ記事に書きたいと思います。回答を読めば、トランザクションのコミット、準同期レプリケーション、MySQLのクラッシュリカバリ、ストレージエンジン(InnoDB)クラッシュリカバリの内部挙動について理解できるでしょう。同時に、私がこれまで見聞きしてきたいくつかの誤解についても糾したいと思います。まずはそれら誤解の一つから始めましょう。 こうした誤解の一つは以下のようなものです(これは正解ではありません):準同期レプリケーションが有効になっているスレーブは常に

    mapk0y
    mapk0y 2019/04/28
  • CharsetとCollationの設定がMySQLのパフォーマンスに与える影響 | Yakst

    MySQL 8 は MySQL 5.7 より常に高速とは限らない(MySQL 8 is not always faster than MySQL 5.7) に続いて、 今回は、データがメモリに収まっており、CPUバウンドな、read only のとてもシンプルなワークロードのテストをすると決めました。このワークロードにIO処理はありません、メモリとCPUの処理だけです。 テスト環境 環境のスペック Release | Ubuntu 18.04 LTS (bionic) Kernel | 4.15.0-20-generic Processors | physical = 2, cores = 28, virtual = 56, hyperthreading = yes Models | 56xIntel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz< Memory T

    mapk0y
    mapk0y 2019/04/16
  • 多分あなたにKubernetesは必要ない | Yakst

    trivago社の小規模な開発チームがコンテナオーケストレーターとしてKubernetesではなくNomadを採用することになった経緯と理由について、両プロダクトの特徴やユースケースに言及しつつ紹介されています。 [HashiCorp][Kubernetes]原文 Maybe You Don't Need Kubernetes (English) 原文著者 Matthias Endler 原文公開日 2019-03-21 翻訳依頼者 翻訳者 msh5 翻訳レビュアー doublemarket 原著者への翻訳報告 1904日前 Twitterで報告済み 1903日前 原著者承諾済み 編集 スクーターに乗った女性(イラスト画像の作成元はfreepik、NomadロゴはHashiCorp) Kubernetesはコンテナオーケストレーションの巨人です。世界中で巨大なデプロイメントを動かしています

    mapk0y
    mapk0y 2019/04/03
  • MySQLのInnoDBプライマリーキーのチューニング | Yakst

    [MySQL]原文 Tuning InnoDB Primary Keys - Percona Database Performance Blog (English) 原文著者 Yves Trudeau 原文公開日 2018-07-26 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 2055日前 原文へのコメントで報告済み 編集 良いInnoDBプライマリキーを選ぶことは、パフォーマンスチューニングの方向性にとても重要です。この記事では、あなたのワークロードに応じた最適なプライマリキーを選ぶための方法を紹介したいと思います。 Percona社のプリンシパルアーキテクトとしての私の責務の一つは、顧客のデータベースをチューニングすることです。パフォーマンスチューニングに関連する側面は多く存在し、それがこの仕事を複雑、かつ大変興味深いものに

    mapk0y
    mapk0y 2018/11/05
    pt-query-digest の読み方はとても参考になる
  • 「20年以上プログラミングしてきた人しか知らないこととは?」に対するJohn Byrd氏の回答 | Yakst

    Quoraでの質問に対する回答の翻訳。長らくコンピューターの世界に身を置いている人間からの、ウィットに富んだ回答。 ソフトウェア開発におけるあらゆることは、既に発明されてしまっています。人々は、それを再発見し、あたかも初めて見つけたかのようなフリをしているだけです。あなたがかっこよくて新しいと思ったものはすべて、Smalltalk、HAKMEM(訳注 : MIT AI研究所で書かれた、アルゴリズムや理論などが書かれたメモ。Wikipedia英語版)、Ivan Sutherland(訳注 : Wikipedia語版)、Douglas Engelbart(訳注 : Wikipedia語版)、初期のIBM、あるいはBell Labsからのコピーでしかありません。 コンパイラーを信じてはいけません。ツールを信じてはいけません。ドキュメントを信じてはいけません。自分のことも信じてはいけません

  • MySQLデータベースパフォーマンスのためのLinux OSチューニング | Yakst

    Percona Database Performance Blogの翻訳。Linux上でMySQLサーバを運用する際の、カーネル、ファイルシステム、メモリなどのチューニングのポイントをまとめた記事。 [MySQL][Linux]原文 Linux OS Tuning for MySQL Database Performance - Percona Database Performance Blog (English) 原文著者 Spyros Voultepsis 原文公開日 2018-07-03 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー taka-h 原著者への翻訳報告 1868日前 原文へのコメントで報告済み 編集 この記事では、MySQLデータベースサーバーのパフォーマンスチューニングと最適化のために調整する重要なLinuxの設定を復習します。OSのチューニングに使う

    mapk0y
    mapk0y 2018/09/21
  • さようならPython、こんにちはGo | Yakst

    以前はPythonで書いていたようなタスクを、最近ではGoで書くようになったという筆者による、Pythonと比べたGoの良さ、あるいは足りない部分のまとめ 私は、以前はPythonで書いていたようなたくさんの処理でGo言語を使っています。たとえば下記のような処理が挙げられます。 Amazon S3に保存されているCloudfrontのログの処理 S3内外への巨大な(テラバイト級の)ファイルを移動する処理 データベースとS3間において同期済ファイルのマッチングする処理 ほんとんどが一度きりの処理であり、そのためスクリプト言語で書くことが理想的です。そのプログラムは、すばやく書く必要があり、すぐに捨てられる可能性が高いです。いつもこれらのタスクは新しくユニークなものだから、再利用できるコードは最小限となります。 以下に、Pythonの代わりに、Go言語を利用することの優位点を挙げます。 コンパ

  • MySQLのストアドプロシージャ、ファンクション、トリガーのパフォーマンスが悪いのはなぜか | Yakst

    MySQLのストアドプロシージャ、ファンクション、トリガーの性能が良くない理由について解説した記事。 実際のテストケースを交えながら、性能が落ちてしまうケースについて考察しています。 [MySQL]原文 Why MySQL Stored Procedures, Functions and Triggers Are Bad For Performance - Percona Database Performance Blog (English) 原文公開日 2018-07-12 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告 1928日前 原文へのコメントで報告済み 編集 アプリケーション開発者は、MySQLのストアドプロシージャ、ファンクション、トリガーをよく作成します。しかしながら、私が知る限り、MySQLのストアドルーチンを使うと

  • MySQLがメモリー不足の時に何をするか : トラブルシューティングガイド | Yakst

    MySQLがメモリー不足で停止してしまった(OOM Killerに停止させられた)時に確認すべき項目を紹介する。特に、MySQLのバグでメモリリークが起きている可能性がある場合に手がかりを得る方法について。 [MySQL]原文 What To Do When MySQL Runs Out of Memory: Troubleshooting Guide - Percona Database Performance Blog (English) 原文著者 Alexander Rubin 原文公開日 2018-06-28 翻訳依頼者 翻訳者 doublemarket 翻訳レビュアー kakuka4430 原著者への翻訳報告 1948日前 原文へのコメントで報告済み 編集 クラッシュした時のトラブルシューティングが楽しいタスクであったためしはありませんが、クラッシュの原因をMySQLが教えてくれ

  • MySQL5.7からMySQL8.0へのインプレースアップグレード | Yakst

    [MySQL]原文 INPLACE upgrade from MySQL 5.7 to MySQL 8.0 | MySQL Server Blog (English) 原文公開日 2018-06-08 翻訳依頼者 翻訳者 kakuka4430 翻訳レビュアー doublemarket 原著者への翻訳報告未報告 免責事項 この記事はMySQL Server Blogの投稿 INPLACE upgrade from MySQL 5.7 to MySQL 8.0 をユーザが翻訳したものであり、Oracle公式の文書ではありません。 ============================== MySQL 8.0のGA版が4月に発表され、多くの新機能が実装されました。新機能の概要やMySQL8.0での改良点については、こちらの記事で確認できます。 MySQLサーバはINPLACEとLOGICAL、

    mapk0y
    mapk0y 2018/06/29
  • InfluxDBのOpenTracing対応: 分散トレーシングのオープンスタンダード | Yakst

    マイクロサービスの構成が増えるにあたりシステムが複雑化し問題が発生した際の原因究明が困難となり分散トレーシングの必要性が高まっています。一方でこの計装はとても大変で、これに対しOpenTracingはベンダーに中立な標準規格を目指しこれを簡易化可能としています。InfluxDataはこれに対して、TelegrafのZipkinプラグインを提供しています。またInfluxDBはトレースのデータ保存にも構造的に最適なデータストアと考えており、InfluxCloudサービスでOpenTracingを実装中です。 [InfluxData]原文 OpenTracing | Open Standard for Distributed Tracing | InfluxData (English) 原文著者 GIANLUCA ARBEZZANO 原文公開日 2017-10-25 翻訳依頼者 翻訳者 tak

  • MySQLの高可用性構成の展望2017年版(赤ちゃん編) | Yakst

    シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションはGaleraとの違いについて、プロキシには幾つかの選択肢があること、分散ストレージではオープンソースのAuroraのようなデーターベースが可能になることなどが述べられている。 この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。 最初の記事では10年以上前から存在していた技術である「長老」を見ました。(訳注:長老編日語訳)第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。(訳注:大人編日語訳)この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication(グループレプリケーション

  • MySQLのヒストグラム統計 (MySQL Server Blogより) | Yakst

    MySQLでもついにヒストグラム統計を利用した実行計画作成がサポートされるようになりました。作成/削除の方法やどのようなときにインデックスと比べて有利か、などについてご案内します。 免責事項 この記事はErik Frøseth氏によるHistogram statistics in MySQL(2017/10/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0.3では、ヒストグラム統計を作成しオプティマイザがより多くの統計情報を利用できるようにすることができます。このブログ投稿では、どのようにヒストグラム統計を作成し、どのような時に役立つかについて説明しようと思います。 ヒストグラムとは何か クエリーオプティマイザはデータベースの中で、SQLクエリーを可能な限り最も効率の良い実行計画に変換する役割を担っています。 時にはクエリーオプティマイザは最も効

    mapk0y
    mapk0y 2017/11/01
  • MySQLの高可用性構成の展望2017年版(大人編) | Yakst

    以前公開された「長老編」(https://yakst.com/ja/posts/4656) に引き続き、比較的新しいMySQL高可用性オプション(大人たち)について解説した記事。前回同様、初心者向けに「Galera」と「RDS Aurora」の2つを紹介している。 この記事では、いくつかの高可用性ソリューションについて考察を行います。 このシリーズの前回の記事(訳注:日語版はこちら)では、長きにわたって利用されてきたMySQLの高可用性ソリューションを取り上げました。私はこれらを「The Elders (長老たち)」と名づけました。レプリケーションなどは今でもよく使われており、MySQLの新バージョンがリリースされるごとに改善されています。 この記事では直近5年間で登場し、なおかつコミュニティの中で牽引力を増している高可用性ソリューションに着目します。私はその中から2つのソリューションを

    MySQLの高可用性構成の展望2017年版(大人編) | Yakst
  • MySQL 8.0のすぐに使えるパッケージの改良 | Yakst

    MySQL 8.0に「サーバーのメモリー量に応じて自動でパラメーターを設定する」ための innodb-dedicated-server が導入される予定です。この機能と導入の背景を紹介します。 免責事項 この記事はMySQL Server Blogの投稿 Plan to improve the out of the Box Experience in MySQL 8.0 をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0において我々は innodb_dedicated_server=bool と呼ばれる新しいパラメーターを導入するつもりです。 これがONに設定されている時、このオプションはシステムメモリーの量を確認し、以下のルールに従って自動的にパラメーターを決定します。 innodb_buffer_pool_size server_memory <

    mapk0y
    mapk0y 2017/08/31
  • 超高速な開発ができるわけ | Yakst

    あるひとりの人がシステムを作ったが故にそのシステムに精通している場合に、最も生産的な開発が行われる。しかしこれは、ひとりの人がシステムの面倒を見ることを超えてシステムが成長する時には矛盾してしまう。 ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。 ヒント : 開発者の話ではなく、状況が大きなカギ。 生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時?それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュール