Author Archives: Jonathan Sundqvist

1. 自前のChaos Monkeyを構築する

   December3日2015年 1:00 am Comments Off on 自前のChaos Monkeyを構築する

   2012念に Netflix は クラウド言語でクールな響きの名前の一つを導入しました。

   Chaos Monkeyができることは、非常にシンプルです。 It それはAmazon Web Service上で稼動し、唯一の目的はランダムにプロダクションのインスタンスを一掃することです。

   それらの意図的な失敗の背後にある理論的根拠は、しっかりしています。

   Chaos Monkeyをインフラストラクチャに設定することで、いろいろなことを処理してくれて、アプリの強化に役立ちます。復旧が進み、定期的に改善できるようになると、ユーザーへの多大な影響はなく、実際の問題に対処できるようになります。

   当社のMonkey

   当社は、AWSやJavaを使用していないので、簡単なPythonスクリプトの形で自社のライトなMonkeyを構築することを決めました。結果としては、同じです。そこで当社は、それをシステム上に解き放ち、それがランダムにプロダクションのインスタンスを探し出し、破壊するのを観察しました。

   それらの自傷行為のインシデントから観察したこと、その後でインフラストラクチャ上でChaos Monkeyを使用する際に考慮すべきかについて、注意事項を以下に紹介します。

   

   設計上で考慮すべき点

   1.営業時間中にカオスのイベントを引き起こす

   夜中に不要なオンコールイベントでエンジニアを起こすことは、決して良いことではありません。しかし、実際の故障は、毎日24時間起こりうります。Chaos Monkeyに関しては、それらに対応して修正する人たちがいる際に、失敗を引き起こすのが最善です。

   2.どれだけ不確定要素を入れるか決める

   Pythonスクリプトが、カオスのイベントを引き起こす時には、HipChatルームでメッセージを受け取り、誰もが何かおかしなことがないかを確認できます。

   メッセージは、どのような障害が何であるかは指定しません。そのため、実際の障害停止の場合と同じように、アラートを選別し、どこに障害があるかを判断する必要があります。すべてのこの「ソフト」の警告は、エラーの発生の見過ごしを軽減するだけです。

   3. いくつかの故障モードを発生させる

   インスタンスを強制終了するのは、障害をシミュレーションするには良い方法ですが、それではすべての不測の事態をカバーしていません。Server Density では完全または部分的な障害を引き起こすために、SoftLayer APIを使用しています。

   例えば、サーバーの電源停止は、完全な故障​​の原因となります。一方で、インターフェイスをネットワーク無効にすることで、ホストが稼動し続けることができる部分を故障させます（そしておそらく当社の監視サービスにレポートを送信します)。

   4.連続的なイベントを引き起こさない

   もし、Chaos Monkeyを解き放つのに悪いタイミングがあるとすれば、それは以前のカオスのイベントのすぐ後です。特に、発見したバグがまだある場合は、また修正されていません。

   当社では、次の失敗を引き起こす前に、数時間を待つことをお勧めします。チームが問題解決のために一日中時間を費やしたいなら話は別ですが。

   5.イベントの発生確率を調整する

   現実のインシデントは、少しも期待している時に起こる傾向があります。カオスのイベントについても同じです。たまに起こるように設定してください。。ランダムにしてください。数日など間隔をおいてください。それはオンコールの準備ができているかのテストの最適な方法です。

   初期の結果

   当社は、かなりの長い期間に渡り、カオスのイベントを引き起こしてきました。これまでに発見した問題のいずれも、サーバーソフトウェアによって引き起こされたものではありませんでした。実際には、ロードバランサ(Nginx) 及びデータベース（ MongoDBの）でのフェイルオーバーのようなシナリオが非常にうまくいきました。

   当社が見つけた一つ一つのバグは、自身のコードの中にありました。当社のアプリがフェールオーバーモードでどうやりとりしているか、自分たちで書き込んでいないライブラリがほとんどの原因でした。

   当社の一番最近のカオスの実行では、2つの連続したMongoDBサーバーのフェールオーバー中に、不可解なパフォーマンスの遅延がありました。長いダウンタイムになるようサーバーを再起動すことは、実行可能な長期的な解決法はありませんでした (>5 分)。

   当社が適切にMongoDBのドライバを起動していなかったと分かるまで、調査に数日間を要しました。

   カオスによって引き起こされるアプリの遅延が勤務時間中に起きました。当社のオンコールエンジニアが通知される待つのではなく、すぐに問題を発見することができ、調査が困難である場合には応答することができます。

   このようなことを発見で、バグの報告や、当社のソフトウェアの耐障害性の向上に役立ちます。もちろん、それはエンジニアリングにとっての余分な時間と正しく物事を遂行するための努力を意味します。

   ようやく

   Chaos Monkeyはインフラが未知の障害状態の下で、どのように動作するかテストするための優れたツールです。ランダムシステム障害にを引き起こし、対処することによって、製品やサービスを強化し、より弾力性ができます。稼働時間の指標やサービスの全体的な品質への利点は明らかです。
   もし、このすべての練習にクールな名前あれば、なお良しということです。

   *編集者注：この記事は元々は2013年11月21日に掲載され、正確性と包括性のために、改訂されました。 *

2. MongoDBを時系列データベースとして使用

   November26日2015年 1:00 am Comments Off on MongoDBを時系列データベースとして使用

   当社は2009年から時系列データベースとしてのMongoDBを使用してきました。

   MongoDBは、当社の サーバ監視 サービスで収集した時系列データのボリューム拡大に対応して、スケールアップするのに役立ちます。　長年に渡り、当社は月に40GBから250TB以上までのデータ処理を行ってきました。

   長年に渡って、当社のサービスに役立ってきましたが、私は必ずしも、MongoDBが時系列データのための最高の可能なデータベースと提唱していません。それは当社がこれまで使用してきたというだけで、（当社は常にいろいろな選択肢を検討しています）。

   その上で、私はMongoDBの使用方法について何度か書いたことがあります。（ここで当社の時系列グラフの背後にある技術）でご覧頂けます。 Story of the Payload_のキャンペーンの一環として （お楽しみに！ ）　その内部の仕組みを詳しく、クラスタ設定を再検討しようと思いました。

   ハードウェア

   当社は長年に渡り、様々なインフラの選択肢を試してみました。これらの中にはGoogle Compute Engine、AWS、SSDs対するスピンするディスク、VMWare、そして現在からの マネージドクラウドからSoftlayer への移行があります。当社ではUbuntu Linuxで標準化し、以下のようにクラスタが設定されています。:

   Ubuntu Linux 12.04 LTS

   私たちは、 LTSのリリースですべてのサーバーを運用し、固定のスケジュールで次のLTSにアップグレードしています。当社のチームは、新しい機能やバンドルされたライブラリにアクセスする必要がある場合、特定のアップグレードをスピードアップすることができます。

   ベアメタルサーバー

   当社は過去に仮想マシンで実験し、保証されたディスクI / Oパフォーマンスでもホストの競合に問題があることを見つけました（ AWS EBSまたはCompute EngineのSSDのような製品は、SOFTLAYERとは異なり、このオプションを提供しています）。

   Solid State Disks

   当社は、複数のSSDが保有しておりー、ジャーナルを含む各データベースを独自のディスクに収納しています。
   すべてはPuppetで管理されています**。

   当社は独自のマニフェストを作成するために使用しました。オフィシャルの Forge MongoDB モジュールがそれ以来、より良いオプションとなる、それに移行しています。
   サーバー自体については、以下のようなスペックです。:

   • x2 2GHz Intel Xeon-SandyBridge (E5-2650-OctoCore) (全部で16コア)
   • 16x16GB Kingston 16GB DDR3
   • x1 100GB Micron RealSSD P300 (MongoDBジャーナル用)
   • x2 800GB Intel S3700 Series (データベースにつき１つ)

   MongoDB クラスタ

   当社は現在の環境を18ヶ月間使用してきました。この間に、当社は垂直的（RAMを追加）もっと破片を追加）及び水平的に（シャードを追加）スケーリングしました。詳細とスペックは以下の通りです。:

   • x3 データノードレプリカセット及び１つのシャードごとにアービター.
   • Washington DCのプライマリデータセンターにx2ノード、 San Jose, CAにフェイルオーバーノード. アービターはDallas, TXの３つ目のデータセンターに収納。
   • アイテム（例、サーバ）のIDおよびメトリックに基づく配分のX5シャード。これは、最大の可用性のために複数のシャードで顧客の記録を分割します。MongoDBは、ハッシュベースのシャーディングを使用してバランスを保ちます。
     *平均負荷は1ミリ秒あたり6000回の書き込みで、 １日あたり約5億の新規ドキュメントと相当になります。

   • 当社は MongoDB クラウドバックアップサービス を使用しており、これによりリアルタイムでオフサイトのバックアップができます。それぞれのレプリカセットでレプリカノードとして機能します。 すべての書き込み操作の（コンパクト、圧縮）のコピーを受け取ります。現在のスループットは、42 Mbpsを保っています。

   • 当社ではGoogle Compute Engine 及びMongoDB クラウドバックアップサービスAPIを利用して、 バックアップの復元 をして、１日に２回にプロダクションのクラスターと照合しています。
   • 当社では、最終的な災害復旧オプションとしてヨーロッパでGoogleのクラウドストレージ内にバックアップのコピーを保持しています。10日間に遡って、 1日2回のコピーを保存します。

   データ

   クラスタの書き込みのワークロードは、ほとんどは挿入および更新で構成されています。

   最下位レベルのデータのために、新しいデータが挿入され、更新されない時には、当社は追加専用のスキーマを使用しています。これらの書き込みは約2-3ミリ秒かかります。

   時間平均タイプのメトリックでは（当社はそれらを永遠に保存しています – [監視グラフ](https://www.serverdensity.com/monitoring-graphs/”Server Density Monitoring Graphs”) を確認ください) 、当社は一日ごと、メトリックごとに、アイテムごとのたりのドキュメントを割り当てをしています。

   このドキュメントは、合計やカウントで更新されます。そこから、当社は、データを照会する際の平均値を計算します。この書き込み作業が完了するまでに大体500ミリ秒かかります。

   当社は書き込みを最適化し、フィールド修飾子を使用、事前割り当てにより文書の増加を避けています。 そうであっても、ドキュメントの更新に関連して、多大なオーバーヘッドがあります。

   データを照会する際には（例　グラフを描く）、ユーザーが経験する平均応答時間は189ミリ秒です。応答の中央値は、 39ミリ秒であり、 95パーセンタイルが532ミリ秒で、 99パーセンタイルは1400ミリ秒です。大部分の時間は、APIのレスポンスを構築するので、アプリケーションコードによって使用されます。クエリの最も遅いのは、広い時間の範囲にわたって複数の項目とメトリックがある場合です。アプリケーション・コードを除外した場合は、MongoDBの平均クエリ時間は0.0067ミリ秒です。

   要約

   これが、Server DensityでのMongoDBクラスタ設定です。みなさんのご意見をお聞かせください。どのようにMongoDBを使用していますか？ご使用のクラスタはどのような形態ですか？また時間ととものどのように進化していますか？

3. DevOpsオンコール：スケジュールの管理方法

   November19日2015年 1:00 am Comments Off on DevOpsオンコール：スケジュールの管理方法

   私は365日、毎日24時間オンコールの状態でした。

   その通りです。当社が サーバー監視 サービスを2009年に開始した時に、自分だけがシステムのことに精通しており、常にオンコールの状態でした。

   どのような状況が分かると思います。片手でコードを作って、もう片方の手でプロダクションのアラーとに応答しているような’感じでした。

   やがて、より多くのエンジニアがチームに加わり、もう少しプロダクションのインシデントを処理する方法について意図的に対処できるようになりました。本投稿では、チームメンバーの間で、当社のオンコール作業負荷を分散する方法についての詳細及び現在のエスカレーションプロセスの考え方について概説します。

   DevOps オンコール

   製品の開発と製品に問題がある場合に、生産上のアラートへの応答は、異なりますが、非常に絡みあってます。だからこそ、やらねばならないのです。

   私たちは生産での製品のパフォーマンスと開発の努力を遮断した場合、優先順位と結びつかないことが起こりえます。コードの復元は、新機能の開発と少なくとも同じくらい重要です。その点では、生産の問題を開発者やデザイナーを露出することは大きな意味があります。 DevOpsの支持者として、これは良いアイデアだと思います。

   待ってください、何ですか？

   ---

   しかしこれは、非生産的ではないでしょうか？コードを書き込む際の心理状態は、生産アラートに応答する場合とそれほど変わらないはずです。

   エンジニア（およびそのことに関わる誰も）が複雑な仕事に取り組んでいる時に、あなたがすることができる最悪のことは、ランダムなアラートを彼らに出してしまうのは最悪なことです。平均的には一旦中断された後に、猛烈にフォーカスできるようになるためには15 分以上かかります。

   どのようにして実行するか

   この生産性のバランスを適正なものにするためには、細部にわたる検討と綿密なプランニング が必要です。実際には、それは永遠に続く旅のようなものです。当社のように、小さく、成長過程にあるチームにとっては特にそうです。

   このことを念頭に置いて、ここで、当社が生産アラートに対処するための現在のプロセスを紹介します。:

   第一段階

   勤務時間中は、すべてのアラートは、オペレーションエンジニアに行きます。これにより、製品チームが、自らのベストを尽くすために必要な静かな時間を十分に提供します。

   勤務時間外のアラートはは、誰にでも（OPSまたは製品を問わず）行く可能性があります。当社では7日ごとにチームメンバー間でローテーションを組んでいます。当社の規模で、各エンジニアは、オンコールが1週間で、8週間オフとなります。誰もが公平な扱いを受けます。

   第二段階

   エスカレートされた問題は、おそらくコードとは無関係な生産状況に関わっています。そのため、第2レベルのオンコール担当はオペレーションエンジニア間でローテーションを組みます。なぜならば、彼らはハードウェアとネットワークインフラストラクチャーについてより深い知識を持っているからです。

   PagerDutyの設定

   エスカレーションやスケジュールの管理のために、当社はPagerDutyを活用しています。エンジニアが制限時間内に応答しない場合は（SMSと電話で頻繁15分ごとに通知）、必ず誰かが、電話を取ることができるようになっています。

   当社のOPSのエンジニアは、マニュアルのスケジュールを優先する責任があります。誰かが休日か、病気であるか、移動している場合には、ボランティアにオンコールスロットを再配置できるように依頼します。

   

   勤務時間外のアラートは応答者は、オンコールからその後の24時間は休みになります。これは、複数日の夜間に起きていることに対して、社会/健康上への影響に対応するのに役立ちます。

   皆と情報を共有する

   当社は、業務や製品の責任者と毎週ミーティングを開催しています。その目的は、全員に製品全体の状況を伝え、製品チームが、開発の優先順位付けをできるようにするためです。

   私は今はオンコール業務はありませんが（顧客とのミーティングや出張により、オンコールをすることは意味をなさない）、Server Densityのモバイルアプリで(Android and iOS)アラート監視することができます。これにより、当社が使用する他の監視ツールのアプリと一緒にホーム画面上で見ることができます。

   皆さんはいかがですか？どのようにdevopsのオンコールのスケジュールを管理しますか？

4. ラバーダックデバッグの困難から抜け出す方法

   November12日2015年 1:00 am Comments Off on ラバーダックデバッグの困難から抜け出す方法

   1940年にハーバード大学の研究者のチームはMark IIコンピュータのリレーでスタックしている蛾を発見しました。「デバッグ」という用語の起源にいろいろな説があります。人間は初期の段階からからデバッグしています。根本的には、デバッグとは問題解決です。例えば。気候が変化し、淡水の流れ凍結した際に、魚を獲る問題 を解決するといった場合です。ほぼ、電気がない状態で、アポロ13の乗組員を救出する方法を考え出す場合です。

   これは決して簡単なことではありません。

   デバッグ、すなわち問題解決は、 すべての知的機能の中で最も複雑だそうです。人間は長期間に渡ってこれに取り組んできましたが、必ずしもうまくいったり、楽しんでいるというわけではありません。

   実際には、人間は問題解決を避けてきました。

   問題解決は無料ではありません。人間の脳は 体全体のエネルギー消費の約20%しか占めていません。人間はそもそもサバイバルとエネルギーの保存できるように、できているようなもので、考えるということを最後の手段ととらえる傾向があります。
   　

   困難な状況にスタックする

   問題解決について考える時でも、実際にはそうではない場合もあります。私たちは、普通は実際の問題解決を必要としない自動的な活動をデフォルトとし、どのような方法でもグレーなことには無理をしません。( 機能的固定性を確認).

   言い換えれば、考えることよりも掘る方が簡単であるということです。掘るというのはマニュアル作業で、繰り返しの作業です。考えもせずに、掘り続ければ、穴はどんどん深くなるばかりです。深くなればなるほど、多く投資する事になります。困難を深堀するということは、タスクに不均衡な時間を費やしてしまうということです。それは自分たちがやっていることの重要性が（サンクコスト）が歪み、論理自体がが歪みます。

   先週、当社は 監視用のソフトのアラートの待ち/繰り返しの問題を解決するために、困難を深堀するようなことに、開発の時間を数時間割きました。

   当社は、内部の状態の移行に何か問題があったと仮定し、コードのコア・ロジックのトラブルシューティングを開始しました。実際にはバグは他にある事がわかりました。（これはUIがアップデートをすべきでないフィールドをアップデートしていました）。つまり、最初の勘は見当違いであることが判明しました。それ自体に問題はありません。

   その間違った仮定の下で、時間を費やす事は理想的ではありません。自分の仮説に疑問を投げかけるのを辞めてから、例えば自ら投資を始めて時に、リソースの配分ミスが始まりました。

   当社でも、立ち往生する状況を回避する事はできません。しかしながら、そのような事が起きた場合は、それに対処するためシステムを持っています。ここではそれらの5つを紹介します。

   1.フローの復元 – コンテキストスイッチ

   皆さんも感じだことがあると思います。正しい場所にいるという感覚です。素早くタイプができなかったり、インスピレーションを流れ込んで、時間を忘れたりしてしまう時です。

   また何かにスタックしてしまった時などその逆の場合は、自分が考えているようなソリューションや突破口が空間的または精神的に見つからない場合です。つまり、何も前に動いていないのです。

   そのような場合には、起き上がってその場を立ち去った方がいいと思います。当社のメンバーは、会社の近くのChiswick Commons を散歩する事で対処しています。自分たちの思考パターンを置いておき、脳がもっと遠くまでさまようようにするのです。.

   そこでコンテキストスイッチが役立ちます。6週間ごとに皆が予定していた仕事を止め、丸１週間自分が選択した別のプロジェクトに取り組みます。意図的に気晴らしをする目的は、ある一定の時間は問題から離れるためです。自分が戻るまでには、こうすることで困難なことは蒸発しているかもしれません

   最後に、私たちは当たり前と思う場合でも、睡眠のことに言及しないならば不注意といえるでしょう。睡眠は脳を活性化させるだけではなく、神経科学者は インキュベーション効果と呼んでいます。.　私たちが寝ている間に、脳はデバッグしてくれるようなものです。

   2. 問題を説明する

   “シンプルさは究極の洗練である”
   \~ レオナルドダビンチ

   人に物事を説明するときには、私たちはスローダウンする傾向があります。なぜでしょうか？それは話す事で、人は状況から解放されるからです。それではまだ、話に追いつくことができません。

   彼らが問題を理解するためには、最もシンプルな表現を使う必要があります。では、一体どんな問題を解決しようとしているのでしょうか？私たちは修飾語を使います。なぜ私たちはこの問題に時間を費やすのでしょうか？なぜ重要なのでしょうか？またこれまでどんなことを試してみたか、説明します。

   実際はそれは大変なことであるように思われるかもしれません。良い質問にある厳密さは、魔法のように自分を表現するためソリューションとして十分です。良い質問を明言化することで、脳が問題を解決しようとするモードに追い込むのです。

   こうすることで、そこで次のテクニックに移ります。 .

   3. ラバーダックデバッグ – 質問をしてみなさい!

   悪名高いラバーダックは、1999年にthe Pragmatic Programmer.の出版と同時に生まれました。

   ラバーダックはかわいいものです。問題は、それがスマートではないということです。自分たちが扱っている問題の性質を​​理解するためには、余分なまでに説明をする必要があります。従来の方法のように、私たちはスローダウンし、物事を単純化する必要があります。

   私たちはあどけないアヒルの笑顔を見つめて、しばしふとおもうことがあります。これは一番簡単な方法なのか？これは本当にやらねばならないのか？

   これが当社のラバーダックのひとつで、こちらでご覧いただけます。Server Density.

   

   4. ピアリビューとペアプログラミング

   時によっては動きのない物に語りかけることが、実行可能でない場合があります（オープンプランのオフィス？）または、問題解決のソリューションが自分の領域や範囲外であったりすることもあります。

   何も単独では起こりませんし、チームワークが大切になります。コードバディ を持つ事で、スタックしてしまうという恐怖を軽減することができます。そんなことはないかもしれませんが、デバッグが面白くなるかもしれません、

   ピア・レビュー（コード上の多くの人が確認する）は他の開発者と協力し、コードにバグがないことを確認するための最適の方法です。また、ものごとを学び、プロフェッショナルとして成長するための良い方法です。

   5. 事前に計画する

   何か他のことに移る前に、特定の問題をデバッグにどのくらいの個々の努力（時間）を投資するか決めます。

   時には特定のバグと向き合っている時もあります。中にはこれまでより多くのバグを指す、とらえどころのないheisenbugsやフラクタルバグもあります。

   割り当てた時間の終わりに達すると、何か他のことに取り組むことをお勧めします。一つのタスク（バグ）のために、他の優先順位がずれて、プロジェクトの進捗状況が危うくなることは避けてください。

   コンテキスト切り替え、他のものに取り組んで、休んでみてください。そうすれば、新たな気持ちで、バグを再検討し、次のステップ（および優先順位）を決めることができます。

   ここで、デバッグのツールについて述べておきます。セントラルロギング、エラー監視などすることで、バグをいかにすぐに解決するかにおいて大きな違いを生みます。今後の投稿でこのトピックについて説明したいと思います。

   要約

   デバッグ作業は、多くの場合、ゆがんでしまい、自分たちが困難な状況に陥り、生産性の落ちてしまいます。これは、自分が解決に導びかない簡単で反復的なことを繰り返してして、問題解決にならないためです。

   自分が何にスタックしている理解できるようになってください。困難な状況に陥るような兆候を知り、うまく抜け出すようになってください。コンテキストスイッチング、ラバーダックデバッグ、減速、事前の計画などが正しい方向に戻るための実証された手段です。

5. Nagios の代替 – コスト計算

   November5日2015年 1:00 am Comments Off on Nagios の代替 – コスト計算

   業界での一般的な誤解としては、オープンソースの監視ソフトウェアは無料という概念です。

   これはライセンスだけを見た場合、正しい見解ですが、考慮に入れるべき無限の多くの要因が存在します。最適なNagiosの代替品として、当社は当社の サーバー監視. と比較して、いかにNagios がいかに効果であるか実際に調べて見ることにしました。競合会社としてServer Densityの役割は、オープンソースコミュニティの悪事を証明せずに、誤解を招くことなく、 Nagiosを使用する上での問題や難点を強調することです。当社の計算方法への批判も予測しながら、当社はこの「仕組み」に関する記事を書くことにしました。これにより、計算方法について、当社と係わり合うことができます。-もし、当社のやり方が間違っていると思われる場合には、是非ともコメントをください。もし当社を納得させることができるのであれば、計算方法を喜んで修正します。しかしながら、これが当社の検証方法です。

   始める前に

   これらの見出しの多くに共通のテーマが、Nagiosの設定と使用についてあることに気づくでしょう。Nagiosはセットアップと使用に時間がかかります。時間とお金に全く関連のない世界では、Server DensityとNagiosの関係はこのようになります。:

   • Nagios はお金を節約できる。
   • Server Density は時間を節約できる。

   もしくは

   • Nagios は時間がかかる。
   • Server Density はお金がかかる。

   しかしながら、実際にはその通りではなく。古い慣用句である “時は金なり” という表現が、速素早いハイテクのスタートアップの世界にふさわしい表現です。そのためこうなります。:

   • Nagios はお金がかかる。
   • Server Density はお金がかかる。
     これの原理が Nagios のコスト計算の基本になり、設定及びオープンソースのツールのメンテナンスにかかると思われる時間に基づいて、 Nagiosの金銭的価値を計算しました。

   お好みであれば、基本的な監視設定のコストを評価することができますが、
   監視インフラストラクチャーを複製する必要があれば、すべてのオプションをチェックするのが最適です。

   Nagios のコスト計算

   Nagios のハードウエア要件

   Nagiosのサーバーを運用するのは安価ではありません。特に多数のサーバーがある場合には、多くの処理能力を必要とします。

   50 台以下のサーバー

   50台以下のサーバーを監視するためには、当社はAmazon m3.mediumインスタンス・タイプと似たようなことを提案します。これを書いている時点で（2014年11月）1時間に$0.070 と設定しており、これは年間で $613のコストになります。

   50台以上のサーバー

   50台以上のサーバーを監視する場合には、Nagiosのサーバーにより多くを求めることになるので、アップグレードする必要があります。このために、当社はm3.xlargeインスタンスをお勧めします。これを書いている時点で（2014年11月）1時間に$0.280 と設定しており、これは年間で $2452のコストになります。当社は、コストのベンチマークとして、AWSを使用しました。それは彼らが、常にコストダウンを推進しする最も人気のあるプロバイダーだからです。当社は、Server Density.を選択せずに、Nagiosを選択する場合の全体の設定費用である購入前の手数料などで、コスト計算に複雑さが増すので、リサーブドインスタンスを考慮していません。

   冗長性の必要性?

   もし、真剣に監視のことを考えている場合は、冗長性を継続的に確認すべきです。Server Densityが、複数の施設で展開する地理的な冗長性を合わデータセンターの中で、完全な冗長性と展開している方法を複製するのであれば（実際に監視しているよりもより信頼性のある監視

6. Mongodbの監視方法

   October15日2015年 1:00 am Comments Off on Mongodbの監視方法

   ---

   アップデート:
   当社はMongoDBのPaul DoneとMongoDBの監視方法について議論する公開Hangout on Air を開催しました。当社は、このスライドとビデオを作成しており、本ブログの記事の最下部からご利用いただけます。

   ---

   当社では、サーバー監視の様々なコンポーネントを稼動させるためにMongoDBを使用しています。これは、基本的なユーザ・プロフィールから 30TB/月を越える時系列データの高スループットの処理まであります。

   これは当社が、MongoDBクラスターがどのように稼動しているか、システムのすべての面を監視して、細かに目を光らせていることを意味します。本投稿では、主要な指標とMongoDBの監視方法についての詳細について説明します。

   

   MongoDB監視の主要指標

   指標については広大な範囲で様々なポイントがあります。　 MongoDB クラスターには常に注意を払うことが必要ですが、重要なのはほんのわずかです。これらが、当社が考える重要なリストにある監視に関する指標です。

   Oplog レプリケーションの遅れ

   レプリカのセットとしてMongoDBに組み込まれているレプリケーションは、当社の経験ではうまく稼動しています。しかしながら、デフォルトの書き込みは、プライマリのメンバーに受け入れられるだけで、他のセカンダリに非同期に複製されます。 MongoDB はデフォルトで最終的に一貫性があります。. これは、プライマリがフェイルモードの場合には、データが複製されない短い期間が、通常存在することを意味します。これは既知の特性であるため、重要なデータについては、書き込みの不安を調整することができ、データがいくつかのセカンダリに到達してからのみ、戻すことができます。他の書き込みの場合には、セカンダリが遅れるのを知っておく必要があります。なぜならば、これはネットワーク等の問題やハードウェア容量不足を意味しているからです。 共有されたクラスタの大量のデータを移動する場合には、レプリカのセカンダリは時には遅れがでます。レプリカがある特定の時間だけ遅れた場合のみアラートが発信され、30分以内に復旧した場合には、アラートが発信されません。

   レプリカの状態

   通常の運用では、レプリカの一つがプライマリとして、他はセカンダリとして設定されます。これはほとんど変更がなく、もし選択できる場合、, その理由を把握したくなります。 これは通常、セカンダリで発生し、その状態はそれ自体で解決しますが、ハードウェアやネットワークの障害があった可能性があるため、すぐに原因を調査したいと考えます。状態間のフラッピングは、通常の運用条件では起こらずに、例えば、メンテナンスのため、またハードウエア障害などの有効なインシデント発生時において起こります。

   ###ロック％とディスクI / Oの使用率％
   MongoDB2.6については、ロックはデータベースレベルで実行され、MongoDB2.8では進行中のドキュメントレベルでロックされます。書き込みではグローバルデータベースのロックが実行されますが、このような状況が頻繁に起こる場合には、他の操作の問題が（読み込みを含む）キューにバックアップされるのでパフォーマン上の問題が発生します。高い効率的なロック％は、例えば不十分な設定のインデックス、インデックスなし、ディスクのハードウェア障害、不適切なスキーマ設計などデータベース内の他の問題で確認できました。これは、長時間数値が高い時には把握しておくことが重要であることを意味します。なぜならば、サーバの速度が低下し（レプリカの状態に変化を起こし、応答しなくなり）、 oplogが遅れる可能性があるからです。しかしながら、それはあまりに頻繁に引き起こすことになるので、注意する必要があります。例えば、ロックが30分以上75％を超えたままの状態になると、長期の遅延を起こし、レプリカの状態とoplogの遅れのアラートがある場合には、非クリティカルなアラートとして実際に設定することができます。これはディスクのI / Oの使用率％などディスクがどれだけ稼動しているかに関連しています。100％に近づくとディスクが最大容量になっていることを示し、アップグレードする必要があります。SSDにディスクをスピン. If ySSDを既に使用している場合には、RAMを追加で提供したり、データをシャードに分割したりする必要があります。

   

   MongoDB監視の重要ではない指標

   定期的に記録をチェックすべき他の指標もいくつかあります。重要でないかもしれませんが、うまく取り扱い、調査した場合には、プロダクション上の問題にエスカレートする前に問題を回避するのに役立ちます。

   メモリ使用量とページフォルト

   メモリはMongoDBへのおそらく最も重要なリソースであるので、常に十分にあることを確認しておくべきです！経験則では、すべてのインデックスがメモリに収まるように十分なRAMを提供し、できればすべてのデータのための十分なメモリを提供することが必要です。常駐メモリが重要な指標となります。 – MongoDBは有益な統計を提供し 、メモリに何をしているかを示します。ページフォールトは、メモリに関連にしています。それはページフォールトはMongoDBが、データを検索するためにメモリよりもディスクに行く必要がある時に発生するからです。 さらなるページフォルトは、メモリ不足であることを示しており、利用可能なRAMを増やすことを検討すべきです。

   接続

   MongoDBへのすべての接続が、システムの必要なメモリへの負荷になります。これは初期にはUNIXのulimitの設定によって 制限されますが、次第にサーバーのリソース特にメモリーによって制限されます。多数の接続は、高いロック％によりバックアップの要望など他の問題やアプリケーションコードが多くの接続が開きすぎる問題などを示します。

   シャードチャンクの分配

   MongoDBはすべてのシャードを均等にバランスを保つようにしますが、高いロック％ によるmoveChunk操作の遅れなどシステムに制約がある場合には、遅れが出てきます。そのため、定期的にクラスターが均衡を保っているか注視しておくべきです。当社では これを解決する無料のツールをリリースしました。これは、単独で、プログラムまたは Server Densityのプラグインの一部として実行することができます、

   MongoDB監視のツール

   これで、注視せねばならない点やこれらの監視に関する統計を実際に収集するかについて理解いただけたと思います。

   リアルタイムでのMongoDB 監視

   MongoDBの中には、多数のツールが含まれています。これらは、すべてライブでMongoDBサーバーに対して実行されており、リアルタイムで統計をレポートします。

   • mongostat - これはopcounts 、ロック％ 、メモリ使用量と秒ごとに更新するレプリカセットの状態といった主要な指標を示しています。今何が起こっているのか確認できるので、リアルタイムでのトラブルシューティングに便利です。
   • mongotop - mongostatはグローバルサーバの指標を示しますが、 mongotopは、具体的に、読み取りと書き込みの関係で、コレクションレベルでの指標を調べます。これは、ほとんどの活動がどこで起こっているか示すために役立ちます。
   • rs.status() - これは、コマンドを実行するメンバーの観点から設定されたレプリカの状態を表示します。これは、メンバーの状態とそのoplog遅れを確認するのに便利です。
   • sh.status() - これはシャードクラスターの状態特に特にシャードごとのチャンクの数を示し、均衡がとれているか否かを確認できます。

   MongoDB監視、グラフ及びアラート

   上記のツールは、リアルタイムでの監視のために有用ですが、時間をかけて統計に注視し、特定の重要または重要ではない指標がしきい値 に達した時に通知を受ける必要があります。これこそがServer Densityのような監視ツールが必要な理由です。当社はこれらの統計を収集し、労力をかけずにアラートやダッシュボードを設定し、時間の経過とともにデータをグラフ化することができます。

   

   もし、皆さんがNagios やMuninのような自社の監視ツールを稼動しているのであれば、 これらのシステム用の様々なプラグインもあります。MongoDBはそれ自体が
   MongoDB管理サービスの一つとして無料の監視ツール　を提供します。これはServer Densityと同様にアラートやグラフで、上記のような統計を収集しますが、すべての他のシステム、可用性やアプリケーションの監視は含まれていません。

   Monitor MongoDB スライド

   Monitor MongoDB ビデオ

7. Apacheの監視方法

   October8日2015年 1:00 am Comments Off on Apacheの監視方法

   Apache は、オリジナルのバージョンは1995年にリリースされ、多分、最も有名で、広く普及しているウェブサーバーであり、現在 多数のウェブサーバーに配備されています。 古典的なLAMPスタックの重要な一環として、ウェブサービングのアーキテクチャーの重要な構成要素であり、現在してやっていないのであれば、Apacheを監視する必要があります。

   mod_statusでApache 監視を可能にする

   ほとんどの Apache監視のツールは、mod_statusのモジュールの使用が必要です。これはデフォルトで含まれていますが、有効にする必要があります。Apacheの設定にエンドポイントを指定する必要があります。

   <Location /server-status>
   
     SetHandler server-status
     Order Deny,Allow
     Deny from all
     Allow from 127.0.0.1
   
   </Location>
   

   これにより、サーバーでステータスのページがhttp://localhost/server-status にて利用可能になります。. 当社ではこの設定をするための完全がガイドブックがあります。 ExtendedStatusを確実に有効にして、すべての統計に完全にアクセスできるようにしてください。

   コマンドラインからのApacheの監視

   ステータスページを有効にして、上記のように機能していることを確認したら、リアルタイムでサーバーのトラフィックを監視するためにコマンドラインのツールを使用することができます。これは、問題をデバッグし、実際に発生するトラフィックを検査するのに役立ちます。

   apache-top のツール はこれを実現するために、人気のある方法です。それは、例えば、apt-get install apachetop からだけではなく、Pythonの簡単なスクリプトのようにソースからダウンロードすることで時にはシステムパッケージとして利用可能です。

   Apache監視とアラート – Apacheの統計

   apache-topの使用はリアルタイムでのデバッグや、現在サーバー上で何が起こっているか調査するのに役立ちますが、一定期間の統計情報を収集したい場合には、あまり役立ちません。この場合に Server Density のような監視用の製品が役立ちます。当社の監視エージェントは、Apacheサーバーのステータスの出力を解析サポートして、秒ごと要望やアイドル/ビジー状態のWorkerに関する統計を提供できます。

   Apacheにはいくつかのプロセスモデルがありますが、最も一般的には、サービス要求を待っている間に、ワーカープロセスをアイドル状態に保つことです。より多くの要望が来るに従って、より多くのWorkerが設定された最大限の状態になるまでに、それらを取り扱えるようになります。その時点で、要望は待ち状態に入り、ウェブへの訪問者は、遅延を経験します。これは、毎秒の生の要望の監視だけをせずに、どれだけアイドル状態のWorkerがあるか監視することも重要であることを意味します。

   Apacheのアラート設定にアプローチするための適切な方法は、アプリケーションの経験するベースライントラフィックの種類やこれについてアラームを設定することです。アラートの例としては、統計が大幅に高い場合（突然のトラフィックスパイクを示す）や数値が極めて低いです場合（どこかでトラフィックを妨げる問題があることをを示します）があります。また、どのトラフィックレベルでいろいろと減速し始めたり、サーバーが過負荷になるといったことをサーバーをベンチマークできます。 – これは、アラートを発信することができるのにふさわしい上限とすることができます。

   Apache監視とアラート – サーバーの統計

   秒ごとの要望やWorkerの状態といったApache監視の統計は、Apache自体に注視するために役立ちますが、パフォーマンスはサーバーのオーバーロードでも影響を受けます。理想的には、独自の専用インスタンス上でApacheを運用していれば、他のアプリケーションとの競合を心配する必要はありません。Webサーバーは、一般的にCPUによって制限されているので、ハードウェアの仕様は、Webサーバーにできるだけ多くのCPU及び/またはコアを提供する必要があります。より多くのトラフィックがあれば、CPU使用率の増加し、特にApache workerがより多くのCPU時間を占有しているので、使用可能なCPUとコアに分散しています。CPUの％の使用率自体は、必ずしもアラーとのための有益な指標ではありません。それは、数値がCPUごとまたはコアごとになる傾向があり、多くのコアを持っている可能性があるためです。すべてのCPUやコアの中で、平均のCPU使用率の監視を設定する方が有益です。

   Server Densityのようなツールを使用することにより、これを可視化でき、CPUがオーバーロードしている場合に通知を受けるように設定することができます。 – これらの指標を理解し、CPUアラートを設定するための当社のガイドブック が役立ちます。Linuxでは、すべてのCPU間でこの平均値は、平均負荷と呼ばれる別のシステム指標に抽象化されます。これは、パーセンテージではなく小数であり、例えば、CPUへのアクセスを待っているプロセス時間の長さなど、オペレーティングシステムの観点から負荷を把握することができます。平均負荷のための推奨のしきい値は、どれだけ多くCPUとコアを持っているかに依存します。 – 負荷の平均についての当社のガイドブック はさらに詳しく理解するのに役立ちます。

   Apacheのリモート状態の監視

   上記のすべての指標はApacheとそれが稼動するサーバの内部状態を監視しますが、ユーザーの経験を監視することも重要です。これは、外部の状態及び応答時間のツールを使用することによって達成されます。- Apacheインスタンスが世界の地域から（お客様がどこにいても）トラフィックにサービスを提供しているか、また応答時間のパフォーマンスを知りたいはずです。それにより、Apacheサーバの能力を増加させたり、また負荷分散クラスターに多くを追加することで、どの段階でより容量を追加する必要があるか知ることができます。Server Density のビルトインのウェブサイト監視.ようなサービスを利用するのが簡単です。カスタマイズされた場所から、パブリックURLと他のエンドポイントの状態を確認することができますし、パフォーマンスの低下や停電があった場合にアラートを受信できます。

   これは特に自身のサーバーとベンチマークして、ある一定の負荷平均が、エンドユーザーのパフォーマンスに影響を与え始めるか知るりたい場合に、Apacheとリモート応答時間のサーバーの指標を相関させるグラフを作成するのに役立ちます。

8. インシデント対応のガイドブックにはどのような内容が含まれていますか

   October1日2015年 1:00 am Comments Off on インシデント対応のガイドブックにはどのような内容が含まれていますか

   今年の2月に、当社ではすべての運用マニュアルを一元化し、刷新を開始しました。私はいくつかのツールを試してみましたが、Server Density に関するあらゆる情報を保管するためにGoogle Docsを使用することにしました。すべてのインフラの管理についてはPuppetを活用しています。何がインストールされているか、設定、サーバーの管理、フェイルオーバーや配備など、ほとんどすべてのドキュメントを管理しようしていますが、他の文書のドキュメントの管理も必要です。最も重要なのはインシデント対応のガイドブックで、これはアラートが発信された際に、当社の緊急対応チームが対応処理のために確認するすべてのチェックリストです。

   なぜインシデント対応のガイドブックが必要なのでしょうか？

   チームが拡大するにつれて、その場限りのやり方でインシデントに対処する方法をすべてを知っている1人か2人の限られた社員に頼ることができなくなります。システムは複雑化するので、チームのメンバー間で責任を分担して、皆が同じ知識だけ持たないようにする配慮する必要があります。インシデント発生時には、順序だてて正しく対応が行われることが非常に重要です。ここで、いくつかの点に注意を払わねばなりません。:

   • 実行することのすべてを記録します。これは、他の応答者がすぐに状況を把握し、何が行われたかを把握するために重要です。またインシデント解決後に、リビューをすることも重要であり、事後に改善の検討をしていくことができます。

   • 社内及びエンドユーザーとコミュニケーションをとる方法を知る。チームとしてできるだけ効率的であるように心がけてください。しかし、エンドユーザーが何が起こっているか理解できるようにできるだけアップデートした情報を伝えてください。

   • 他のチームメンバーに連絡する方法を知っている。第一対応者が助けが必要であれば、他のチームメンバーにサポートを求めるための迅速な簡単な方法が必要です。

   インシデント発生時のストレスもあり、これらをすべて覚えていることは難しいために、インシデント対応のガイドブックが必要になるのです。これは、警告が発せられた時に、いつでもフォローできる明確なステップがまとめられた手短な文書です。

   インシデント対応のガイドブックにはどのような内容が網羅されるべきでしょうか？

   当社のインシデント対応のガイドブックには、以下のような6つのステップが記されており、その理由を含めて詳細をまとめてあります。実際のドキュメントは、複雑な指示をフォローする必要がないように簡潔であるべきです!

   1. JIRAにインシデントをログ記録します 。当社では、プロジェクト管理にJIRAを使用しているので、すべてのインシデントをログに記録することに意味があります。当社では応答者がアラートを受信するとすぐに、インシデント・チケットを設け、その中にアラートの基本的な詳細が含まれます。問題の診断や解決に関するすべてのステップは、コメントとして記録されます。これにより、インシデントを特定のIDによって言及することができ、他のチームメンバーがどのような事象が起こってるか追跡でき、インシデントのフォローアップタスクやまた事後の改善に結びつけることができます。

   2. PagerDutyでアラートを確認。インシデントがログ記録されるまでアラートを認知することがありません。それでは、認知とインシデントがリンクされているからです。これにより、他のチームメンバーは、誰かが間違ってアラーとを認知して、忘れてしまったのではなく、問題が調査されていることを理解することができます。

   3. Hipchatのオプスウェールームにログイン。[当社では、Hipchatを使用しており]、チーム間のリアルタイムのコミュニケーションをとったり、継続中の障害について討議するためだけに、別の「ウォールーム」を使用したりしています。当社ではコックピットルールを使用　これにより、タイムスタンプでソートされて、何が起こっているか理解することができます。時には、話す方がタイプするよりも早いので、何かについての討議やアクションについて調整をする際には、電話に切り替えることもあります。（Google HangoutsはCPUへの負荷が高すぎるので、通常はSkypeを使用します！）。その際にでも、関連のJIRAのインシデントのチケットには詳細をログ記録します。

   4. インシデント対応のGoogle Docsフォルダを検索し、既知の問題を確認。当社では、
      配備されたデバッグの系統または時にオンコールアラートになるような既知の問題のリストを保有しています。ほとんどの場合には、あらゆるタイプのアラートについてのドキュメントがあり、エアーの系列により検索ができ、デバッグのステップなどの正しいドキュメントを見つけることができます。自動スクリプトで解決できるような問題については、できるだけ実際の人にオンコールのアラートを投げかけないようにしており、これらのステップでは問題の原因を追跡するのに役立つデバッグのステップになります。

   5. 問題がエンドユーザーに影響を与えている場合は、 ステータスのサイトに投稿を行う。当社のシステムの設計により、当社の製品に使用に影響を与えるようなインシデントは稀にしかありません。しかしながら、お客様に影響を及ぼすような問題がある場合には、パブリックのステータスのページに投稿します。 当社としてはできるだけ詳細の情報を提供し、何もレポートすることがない場合にも少なくとも30分ごとに分かる範囲でできるだけアップデートを投稿します。自分の問題を公開することは良いことであるという考えは、直感に反することと思われるでしょうが、問題が発生している時に、頻繁にアップデートすることに関して、お客様は概して好意的に反応します。これは問題が頻繁に発生することに言い訳にはなりませんが、問題が発生した際に、お客様は状況を知りたいのです。

   6. 自分で問題を解決できない場合には、それをエスカレートする。応対者が、問題を解決できない場合、当社は障害を引き伸ばすよりは、できるだけ早く手助けをすることを好みます。これは、PagerDutyで第二のオンコールチームへのアラートによりエスカレートするか 他のチームメンバーを直接呼び出すかのいずれかです。

   お客様からのメールへの返信

   その他に注意すべき点は、問題を報告することで発生するサポートチケットについてです。必然的に一部のお客様は、パブリックステータスページを認識しておらず、彼らは直接任意の問題を報告します。当社では、 Zendeskは活用し、最初のチケットを「問題」として設定し、お客様を当社のステータスページに誘導します。以後の任意のチケットはその「問題」の「インシデント」として設定され、当社が問題を解決する際には、すべてのリンクされたチケットの一斉返信を行うことができます。ステータスのページから同様の情報が得られない場合、お客様へのメール発信も実践すべきことです。

   @serverdensity Great incident report!

   — Or Weinberger (@orweinberger) August 27, 2014

   ガイドブックにはどのような内容が含まれるべきですか？

   各企業は、それぞれ異なるやり方でインシデントを処理します。当社は長年の経験に基づいて、他の企業がどのように対処し、自社のサービスに一時停止が発生した場合の感情などを理解しながら、プロセスを構築して来ました。一時停止を防ぐために多くのことを実行できますが、それを除去することはできません。従って、それらを処理するためのプロセスを計画するために多大な時間を費やす必要があるのです。インシデント対応のためのプロセスが御社にはありますか？是非とも、コメントを聞かせてください！

9. サーバー監視の再設計：設定アラート

   August27日2015年 2:03 pm Comments Off on サーバー監視の再設計：設定アラート

   サーバ監視ツールは、アラート設定するためのインタフェースを必要とします。しかし、これらのツールの中でどれくらいが先行的と言えるでしょうか？アラートは、監視サーバーで不可欠な一部であり、トライアルを成功させている顧客はいくつかのアラートを設定する傾向があります。当社のお客様であるPreactから収集された分析データーがこのことを証明しています：

   

   当社がアラート設定のUIを再設計するためにちょうど2ヶ月費やしてきた理由はここにあります。この再設計を成功させるためには、ユーザーから多くのフィードバックと大量のデータが必要になります。幸いなことに、受動的および能動的プロセスを通じて、当社は毎日のフィードバックを収集しています。

   　　　　
   • サポートチケットにより、ユーザーがで苦労していることを把握できます。
   • ユーザビリティテストもユーザーが苦労している理由を示してくれます。
   • 顧客のアカウントを調査すれば、ユーザーが当社が提供するどの機能を使用しているか教えてくれます。
   • Analytics分析により、お客様の成功のためにどのようなアクションが不可欠であるか、どこで摩擦を削減するか定義できます。
   • Server Densityを毎日使用することにより、ユーザビリティの問題またどの機能が欠けているかなどが明確になります。

   この新しいUIは、多くの研究、思考、ユーザビリティテストと反復の成果と言えます。この記事の中で、私は、設計プロセスがアラートを設定するための先行的な方法につながったかを共有するつもりです。私は自分たちが解決した問題、どのようにまた何をユーザビリティテストを示したか、最初のコンセプトをいかに改善したかをご紹介します。

   待機とリピートの再考

   サポートチケット、ユーザビリティテストおよび顧客口座からのデータから、ユーザーが正しく待機とリピート時間を使用していなかったことが示されました。また、一部のユーザーは、図像学を知らなかったり、待機とリピート時間を理解していませんでした。

   

   アラート設定においては、待機時間が以下のような質問への回答を教えてくれます。:すぐに通知されるようにしますか、それとも自分が気にするまでその状態を数分間持続する必要がありますか？繰リピート時間は以下のような質問に答えてくれます。：問題を解決する前に一度だけかX分ごとに通知を受けたいですか？これらはアラート通知のスパムや疲労を軽減するために、これらはサーバ監視ソフトウェアの重要な部分です。

   これらの概念では、かなりのサーバ監視の経験を必要とします。このように、当社は、UIがこれらの概念を説明すべきであると結論付けました。当社は、アクションを起こせるようなキーワードで完全な文を使用しています。:

   

   これはいくつかの利点があります。

   必要なサーバ監視の知識が包括的に説明があり、理解することが簡単です。
   議論を呼ぶような図解はなし！
   データアラートなしなどエッジケースを説明するために多くのスペース利用可能です。

   ユサビリーティのテスティンゴ：　待機とリピート

   テストでは、新たな待機とリピートのUIは直感的で使いやすいことが示されました。最も有用なテストは、比較的経験の浅いユーザでした。彼は、 UIがデフォルトの待機で構成されていた場合には、より迅速にテストを完了したでだろうと提言しました。以下のスクリーンショットでは、左側は待機時間なし、右の2分の待機時間を示しています。:

   

   右側の設定の方がより多くを示していますが、それは良いデフォルトでしょうか？顧客データは、デフォルトの待機時間は、サーバ監視ソフトウェアにとって重要である警告スパムを減少させることを示しました。2分のデフォルトの待機時間として、新たにアラートの設定がされてます。秒を使用して待機時間を設定する機能が削除しました。顧客データは、 60秒または120秒よりも90秒の待機時間を設定することが重要ではないことを示しました。そのため、このオプションを削除することにより、UIが迅速に理解できるようになりました。

   メトリックを簡単に見つけられます。

   Server Density では、様々なメトリックを監視することができますし、カスタムプラグインも書くことができます。残念ながら、ユーザビリティテストは、 3つのレベルのメトリックを見つけることは困難であることを示しました。古いUIは、一般的なドロップダウンを多用しました：

   

   これは、うまくいきましたが、それはユーザビリティの問題がありました：

   手動で3レベルのアイテムを見つけるために時間がかかります。
   ホバリングや誤ってクリックすると、容赦がありません。再起動する必要があります！
   ドロップダウンは、スペースがかなり多くを占めています。
   キーボードコントロールをサポートしていません。

   当社は1月に新たな「アコーディオンドロップダウン」を実装した最新の値のウィジェットをリリースしました。:
   

   メトリックを見つけることで、ほとんどの問題解決するので、これを使用することにしました。ユーザビリティテストは、すでにこのコンポーネントは使いやすく、強力であったことを示しました。当社はさらなるテストを通して、より良くできると知っていました。

   キーボード操作の改善

   開発者は、キーボードによる操作を好むので、当社はそれらを改善するために多くの時間を費やしました。 8種類のユーザビリティテストのフィードバックが、 20以上の改善点につながりました。これらの改善点は、アラートを設定を迅速に作成を可能にするキーを押すことへに直感的に反応できるUIを開発しました。しかしながら、これは容易ではなかったので、私はユーザビリティテストが明らかにしてくれたポイントをご説明しましょう：

   • 可能な限り、ネイティブの要素を使用する。
   • 機能性をコピーし、ユーザーの期待にマッチできるように、ネイティブの要素から動作を拡張。
   • スペースバーだけでなく、ダウン、アップ、入力や終了キーに反応する要素を選択し、それらを閉じる時に焦点を当てる。
   • 単一の相互作用を見逃さない：詳細キーボード管理を実行すれば、それが欠けている場合耳障りになります。
   • フォーカスのスタイルは非常に重要であり、ブラウザ間で非常に矛盾しています。
   • 1つのキー入力は2つ以上よりも無限に使いやすい。

   検索は、経験豊富なユーザーにとっては強力なツールですが、経験の浅いはユーザが必ずしも正しく、それを使用していません。将来的に経験の浅いユーザーを助けようするために、ユーザーの期待にマッチしているかを確認するよう当社は検索の記録を開始します。また、当社はスペルミスや代替の命名の規則の許容範囲内に構築するAlgolia（当社のお客様）を探索します。半自動的にアラートを設定するのは、もう一つのオプションです。

   当社は、キーボード操作の結果に非常に満足しています。今では複数のアラートを設定するには、ほんの数秒ですみます。開発者は、自分のコンピュータと対話するために多くの時間を過ごす方法と一致するために、この機能に力を入れてきたことを喜んでいます。

   小さな画面上の利便性を向上

   サーバ監視インタフェースは、かなり多くの情報を示しています。アラートの設定は、プロセス名、 HTML文字列、1つのフィールド、 3つのフィールド、 4つのフィールドまたは5つのフィールドをを含むことができます。これらのフィールドが窮屈になると利便性が低下します。

   当社は、スペースを節約する必要がありました。1つのオプションは、スペースを大量に保存したテキストだけを残して、パディング、マージン、ボーダーとシャドーのようなすべてのビジュアルツールを削除することでした。：

   

   しかし、利便性の懸念がありました。ユーザーは、この設計に対処する方法を知っていますか？当社は、後ほどこれをテストすることになります。

   当社はお客様のアカウントを調べ、開発者に話を聞きました。そこで以下のようなことが明らかにしなりました：

   • アラート設定が有効である場合、ユーザのエラーにより無効な場合は、それは重要ではありません。
   • 少なくとも一つのアクションが実行されると知っておくことが重要です。
   • どのアクションが実行されるか知ることはあまり重要ではありません。
   • 待機、リピート、アクションの設定はは、単一のドロップダウンの内側に隠すことができます。
   • 検証エラーがある場合は、警告がオンになっていると確認することは重要ではありません。

   これらの調査結果を使用して、提案したすべてのデザインは、スペースを節約できました。それでも、アラート設定が複数行にラップすべきであるという事実に対処しなければなりませんでした。課題は、読みやすさを犠牲にすることなく、これを実行することでした。

   ラッピングを引き起こす可能性が最も低いアラート設定の一部は、メトリック、比較値によって構築される文です。例えば、ディスクの使用率が90％以上でした。当社の以前の実装では、この文は対象で中断されました： / devに関するディスク使用率が90％以上です。/ devの対象を文の最後に移動させることにより、ラッピングはより破壊的でなくなりました。それから以下のアラート設定とブレンドさせないように、新しい行の最初の要素をインデントしました：

   

   より多くのスペースを節約するために、ユーザーが最低限のアラートを設定することを表示しています。開発者に話をすると、彼らは初めに「比較メトリック値」という文を期待していることを示しました：

   

   ユーザーがメトリックを設定したら、アラート設定の残りの部分が表示されます。ユーザーはより多くの情報の検証エラーを見ることができました。

   

   ユーザーはこのプロセスを終了すると、検証エラーがオン/オフ切替えによって置換されています。

   

   これにより、スペースを節約できましたが、フィールドが次第に明らかにされるように簡単なアラート設定することができました。これにより、ユーザーは重要なことに集中することができます。

   ユーザビリティテストは、スペースの節約する。

   結局、当社は、テキストベースのアプローチに対して決定しました。

   

   このアプローチでは、ユーザーが対話のために必要な多くの要素を削除しました。これは、ドロップダウンまたはテキスト入力でしょうか？どこでその要素が起動し、終わっていますか？当社は、フォント、フォントの重みと色を使用して、これらの問題を解決しようとしました。しかし、伝統的なアプローチの方が、明らかにより使い易かったのでした：

   

   しかし、当社は、使いやすさを犠牲にしませんでした。これは、モニター·サーバーの非常に重要な部分であり、当社にとっても重要なのです。

   当社はユーザーテスト中に他に決定したことは、ロード及び保存された状態を追加することでした。当社はAJAX駆動型アプリケーションに精通している開発者はそれを見逃すことはないと想定しました。これは真実ではありませんでした。開発者は、変更点の保存の再保証を求めており、当社はロードし、保存された状態を追加しました。

   スペースを節約することは、解決するのが困難な問題でした。サーバ監視ソフトウェアにdevopsチームが運んだデータには柔軟性があり、非常に長くなる可能性があります。最終的に当社は、これを考え出すに多くの時間を費やしたことをうれしく思います。これは、 UIの全体的な使いやすさに大きな違いを生み出しました。

   通知のアクションを明確にする。

   ユーザビリティテストは、統合(HipChat, PagerDuty, Slack, Webhook )を通知するためにアラートを設定することは、直感的でないことを示しました。当社は2つの仮説を持っていました。

   仮説1は、古い受信者のアイコンが混乱を引き起こしたということでした。:

   

   アイコンは、 「ユーザー」または「人」を示し、統合を示してませんでした。当社が提案するそれぞれのアイコンは複数の方法で解釈されるので、代わりにテキストを使用することにしました。

   仮説2は、ユーザーとの統合の両方が含まれていたため、古いリストは直感的ではなかったということでした。開発者は、HipChatチャンネルと同じリスト内に直感的にユーザーを配置していませんか？それは、恐らくありません。最低限サポートチケットで2つの異なる統合が同じ名前を持っている場合に、1つの長いリストが問題を引き起こしたことを示しました。当社は、ワイヤーフレームが以下に示すように、見出しを複数のリストで示すことによって、これを解決します：

   
   当社は、このアプローチを実践し、ユーザーはそれを確認するためにテストするだろう。

   ミスを犯したことを認識する。

   開発中に当社は提案したアプローチに欠陥していることが疑いました。しかし、当社は、第二の再設計にコミットする前に証拠を求めていました。数週間後にユーザビリティテストからのフィードバックが十分な証拠となりました：

   • 特定のユーザを見つけることは困難でした。当社は、ユーザーが検索を使用すると想定していますが、多くは、スクロールすることを好んでいます。
   • ユーザーは必ずしもスクロールできると気づきませでしたが、彼らはスクロールするとイライラしていました。
   • リストはどのアクションが選択されるかを説明するには長すぎました。
   • 誤ってドロップダウンを閉じるのはあまりにも簡単でした。
   • ユーザーは、アラートが開いたときに何が起こるかいう十分な属性を持っていませんでした。

   

   ユーザーがこれをテストすると、結果は圧倒的に陽性でした。私は、ユーザビリティテストは、当初の設計に欠陥があることが証明されたことをうれしく思います。どのくらいのサーバーの監視インタフェースに決して解決のされないこのような種類の問題がありますか？

   アラートを停止する。

   サポートチケットは、少数のユーザーがアラートを一時停止する方法を理解していなかったことを示しました。アラート通知スパムを防止するので、これはサーバ監視ツールの重要な特徴です。

   仮説1は、ユーザーは「休止」または「再生」のアラートを考えていなかったということでした。おそらく、他の用語が必要でした：

   

   仮説2は、単一の再生/一時停止ボタンを使用により混乱したことということでした。歴史的にHi – Fiまたはカセットプレーヤーは、再生や停止用に別のボタンがあり、ボタンを押した時に、ダウンの状態になります。当社のインターフェイスでは、ボタンは再生アイコンに変更します。アラートがオンまたはオフであるため、この機能は、理想的にはトグルに適しています。

   

   このアプローチをテストするために、当社は、開発者にが新しいUIで見たすべてのものを記述するように依頼しました。また、一時停止、再生、停止、オン、オフのような言葉を避けたタスクを設定します。この結果はかなり決定的でした。ユーザーはすぐにこの新しいアプローチを理解しました。使用できるサーバ監視ソフトウェアを開発のための新たな旅立ちへの重要な勝利です！

   オープンアラートを見つける。

   当社の経験で、ユーザーがアラート設定画面に行くための2つの理由があることを分かりました：

   一般的に一度だけ行う新しいアラートを追加します。
   一般的に唯一のオープンアラートに行うアラートを編集します。

   第1の理由には既に満足できましたが、、すでに第2の理由はそうでもありませんでした。解決策は単純に出てきました。それが開いた場合、アラート設定の開いたマーカーを追加します。アラート設定の左側にある赤いバーは、UIの残りの部分とうまくマッチします：

   簡単ですよね?

   実際にはそれほど簡単ではありません。

   驚くことに、サーバーの監視の経験を持つ開発者は赤いバーは、アラートがオープンしたことが示すと誰一人として知りませんでした。。一部の人々は、それは、アラートが無効であった​​ことを意味すると考えて、他の人は、アラートがオフになったことを意味すると考えました。一つの可能な修正点は、通知センターのアイコンの付いたバーを交換することでした：

   

   しかし、これは正しいとは思いませんでした。アイコンは、通知センターへの通信に適していますが、このアラートがオープンの際にはそうではありません。数十億のユーザーの世界的なFacebookのユーザーは、通知アイコンがどのように動作するかを知っているので、当社はそのアプローチを取りました：

   

   オープン·アラートのアイコンは今はないアイコンとして同じスペースを占有するために、既存のユーザーは、最初は混乱しました。しかしながら、新規または経験の浅いユーザーはそのように混乱をしていませんでした。ユーザビリティテストで、既存のユーザーがすぐに適応していることが分かったので、すべての変更をしませんでした。

   サーバー監視のための使い勝手が大切です。

   当社は、新しいアラートの設定UIがサーバー監視におけるユーザビリティのための重要なステップであると考えます。世界中のdevopsチームが間単にサーバー監視をできための多くの高度な機能のの強固な基盤になります。

   

   図像、適切なデフォルト値、キーボードコントロールと全体的な使いやすさなどのいくつかの興味深い情報を提供するのと共に、私はこのポストで手堅い設計プロセスの価値を証明したいと考えています。研究、ユーザビリティテストとその繰り返し、総合的なデザインの一部です。これにより、インターフェイスが直感的で使いやすいものにできるのです。

   新しいUI を試してみたいと思いますか? 今すぐ15日間の無料トライアルを試してみましょう。もし、お客様であるならば、是非とも感想をお聞かせ下さい!

10. 微妙な違い – CPUバージョンのパフォーマンスを追跡

    July27日2015年 1:51 pm Comments Off on 微妙な違い – CPUバージョンのパフォーマンスを追跡

    サーバーのクラスタ内で異常が発生した場合、まず初めにやることはすべての可変的な要素を排除して、構成上の相違を排除することです。多くの場合、これは、小さなソフトウェアのバージョンの違いになりますが、Puppetのような最新の設定管理ツールやChefの使用することで、違いが少なくなる可能性が高いです。

    そこで、何も異常な状態が明らかにならない場合、次のステップとしてはハードウェアを調べることです。これは詳細を調べなけばならない典型的な例であり、インフラストラクチャで何が異常かを理解しなければなりません。

    プロセス

    当社では、インフラストラクチャ全体のパフォーマンス指標のレビューを毎週行っています。これは、自動化された監視やこれらの指標の警告に置き換えるものではありません。しかしながら、時系列的にわずかな性能の低下を見つけることができ、インフラストラクチャ内の問題を調べ、性能の改善に間にあうようにコードベースをスケジュール化して、アップグレードのための準備することができます。 Server Densityを使用するので、Server Density の監視が簡単にできます。それは、通常はパフォーマンスのダッシュボードにあらかじめ設定した時間間隔でチェックするだけで、ほんの数分かかかります。

    これは、これらのダッシュボード上の過去3ヶ月のデータです：
    

    おかしな性能値

    少し前に、当社のクラスターを一つをアップグレードしてから、このようなロードプロフィールが表示されるようになりました。:

    

    これはSoftlayer上で< href=”http://www.softlayer.com/bare-metal-servers” title=”専用のハードウェア” target=”_blank”>専用のハードウェアで実行する、4つサーバー列処理クラスタです。（SuperMicro、 Xeonプロセッサ1270 クアッドコア、 8ギガバイトのRAM ）すべてのソフトウェア·スタックは、Puppet や装備プロセスを使用して同じソースから構築することにより、全く同じバージョンですべてのクラスタノードが実行することができます。

    では、なぜ全く同じタスクで、低負荷を示すサーバーがあるのでしょうか？その差異を理解できなかったので、Softlayer へサポートを依頼しました。: サーバー間で識別可能な差異はないというのが最初の回答でした。

    状況が佳境に入る

    本来同じであるべきなので、そうではないサーバーがあったことに満足できなかったので、当社はさらに問題を調べて、他のことを見つけました。そして、もっと心配な問題を見つけました。- それは高負荷を示した3つのサーバー上でのパケット損失です：

    

    そこでSoftlayerへサポートを求ました。彼らはとても熱心で、これらのサーバーのスイッチ、ネットワークの速度、確立されたか待機中の接続、apache/python/tornado プロセス等を調べました。しかし、最終的には、クラスタ·ハードウェア上での微妙な違いを除いて何も見つかりませんでした。すべてのプロセッサは、 Xeonプロセッサ1270 クアッドコア、 -web4ではV3が稼動していて、すべて最新です。さらに、 -web2と-web3ではV2が稼働して、 -web1はV1が稼働しています。当社が新しいサーバーを注文する場合は、CPUの種類を選んでおり、CPUのバージョンは提供されません。データセンターのチームは手元で準備ができている製品を提供します。

    問題の解決方法

    いろいろと調べた結果, CPUのバージョンにおそらく興味深い差異がいつくかあることに気づきました。 そこで、ハードウエアの差異を取り除いた場合にどうなるか確認しました。

    Softlayer 特別なリクエストに対応しており、この問題を解決する上で何の支障はありませんでした。

    次のグラフは-web1 、その後-web2と-web3の交換したケース示しています。いつそれが実行されたか分かりますか？

    

    それで、クラスターパカエットロスの似ているプロット：
    

    すべてのサーバーを一貫性のあるCPUとCPUバージョンに切替えることにより、問題を解決することができました。パケット損失は消失し、性能は同等になりました。これは、非常に微妙な違いがサーバーの動作に測定可能な影響を与えることを示す良い例です。設定管理により、自分たちが管理できるソフトウェアをすぐに原因から排除することできました。CPUのバージョンがハードウェアドライバーと何らかの問題があったことは考えられますが、ここでは、クラスタ内の一貫性が重要であることを示しています。

×

システム管理及び開発と運用に関する記事にアクセスする

今すぐ登録

×

登録が無事に完了しました！

ご登録有難うございました

日本語のツイッターのアカウントもフォローして下さい。 @serverdensityjp