序章

企業やその他の組織がインターネットベースのサービスにますます依存するようになるにつれて、開発者とシステム管理者は、コストのかかるダウンタイムを最小限に抑える信頼性の高いインフラストラクチャの作成に注目しています。

Webサイト、API、またはその他のサービスが利用できない場合、売上の損失により多額の金銭的コストが発生する可能性があります。 さらに、ダウンタイムは次の原因となる可能性があります。

  • 不幸な顧客とユーザー：ユーザーは安定したサービスを期待しています。 中断すると、サポートリクエストが増加し、ブランドに対する一般的な信頼が失われる可能性があります。
  • 生産性の損失：従業員が仕事をサービスに依存している場合、ダウンタイムは組織の生産性の損失を意味します。 また、従業員がサーバーの再起動とダウンタイムとの戦いに時間を費やしている場合、彼らは新しい機能や製品を開発していません。
  • 不幸な従業員：頻繁なダウンタイムアラートはアラートの疲労につながる可能性があり、問題を解決するために絶えずスクランブリングを行うと、チームとその士気に悪影響を与える可能性があります。

これらの問題に対処するために合体した現代の分野は、サイト信頼性エンジニアリングまたはSREと呼ばれています。 SREは2003年からGoogleで作成され、開発された戦略はサイト信頼性エンジニアリングというタイトルの本にまとめられました。 この分野を読むことは、ダウンタイムを最小限に抑えるための手法とベストプラクティスを探求するための良い方法です。

この記事では、改善によって組織のダウンタイムを短縮できる3つの領域について説明します。 これらの領域は、監視とアラート、ソフトウェア展開、および高可用性です。

これは戦略の完全なリストではありませんが、サービスの本番環境を改善する際に考慮すべきいくつかの一般的なソリューションを示すことを目的としています。

1. 監視とアラート

インフラストラクチャを適切に監視することで、差し迫った問題を事前に監視し、チームに問題を警告し、以前のダウンタイムの原因をより簡単に調査できます。 監視には、システムリソース使用率やアプリケーションパフォーマンスメトリックなどの統計の集計と記録が含まれます。 アラートは、現在のメトリックに対してアラートルールを絶えず評価し、アクションを実行する必要がある時期を判断することにより、このメトリックコレクションに基づいて構築されます。

多くの場合、監視は、メトリックを収集して中央サーバーに報告する各ホスト上のクライアントを使用して実装されます。 次に、メトリックは時系列データベース（タイムスタンプ付きの数値データの保存と検索に特化したデータベース）に保存され、グラフ化、検索、およびアラートに使用できるようになります。 監視ソフトウェアの例は次のとおりです。

  • Prometheus は、さまざまな公式およびコミュニティでサポートされているクライアント（エクスポーターと呼ばれます）からデータをプルできます。 スケーラビリティが高く、アラートが組み込まれており、ほとんどのプログラミング言語で利用できるクライアントライブラリがあります。
  • Graphite は、数十のプログラミング言語とアプリケーションでサポートされる、今やユビキタスなAPIを提供します。 メトリックはノードから中央のGraphiteインストールにプッシュされ、そこで保存およびグラフ化されます。

また、ログファイルを中央サービスにプッシュし、例外やエラー率などの関連するメトリックについてそれらを解析することも一般的です。 Elasticスタック（Elasticsearch、Logstash、Kibana）および Graylog は、ログファイルの解析と分析を容易にするソフトウェアスタックの例です。

監視する指標

信頼性を高め、ダウンタイムを削減しようとするときに収集する最も有用なメトリックは何ですか？

ほとんどの監視クライアントとエクスポーターには、開始点として適した一連のデフォルトメトリックがありますが、アプリケーションまたはサービスには、エクスポートする測定値を決定するときに考慮する必要がある固有のニーズがあります。 ありがたいことに、SREの文献には、監視するのに最も役立つメトリックについての一般的なガイドラインがいくつかあります。 これらのメトリックは、 Four Golden Signals にグループ化され、SREブックから要約されています。

  • レイテンシー：リクエストへの応答にかかる時間。 たとえば、HTTPリクエストに対するサーバーの応答時間。
  • トラフィック：システムで発生している需要の量。 これは、Webサーバーの要求率、ネットワークI / O、1秒あたりのログイン数、またはデータベースの1秒あたりのトランザクション数です。
  • エラー：トランザクションまたはリクエストの失敗率。 すべてのエラーがHTTP500エラーほど明確であるとは限らないことに注意してください。 たとえば、クライアントが500ミリ秒以内に応答を受信することがポリシーである場合があります。 この場合、待ち時間が長い応答はエラーとして表示されます。
  • 飽和度：サービスの「フル」度。 これは、ハードドライブの使用可能なスペース、ネットワークスループット、またはCPUバウンドサービスで使用可能なCPUの量を測定している可能性があります。

指標の視覚化

監視システムを設定したら、収集しているデータを調べたいと思うでしょう。 Grafana は、グラフとダッシュボードを介してメトリックの非常に柔軟な調査を提供するソフトウェアパッケージです。 視覚化は、Graphite、Prometheus、Elasticsearchなどの複数のバックエンドデータソースから集約できます。

アラートの設定

指標を視覚化するだけでなく、問題が発生したときにチームに自動的に警告する方法を設定する必要もあります。 Grafanaには、 Alertmanager コンポーネントを介したPrometheusと同様に、アラート機能があります。 メトリックのアラートルールを定義できるその他のソフトウェアパッケージには、NagaosおよびSensuが含まれます。

アラートシステムをどのように構成するかは、組織によって大きく異なります。 複数のチームがある場合、アラートは、不正なサービスを担当するチームに直接ルーティングされる場合があります。 または、特定の期間のすべてのアラートを処理するスケジュールされたオンコールローテーションがある場合があります。 アラートは、電子メール、プッシュ通知、またはサードパーティのページングサービスを介して送信される場合があります。

覚えておくべき主なことは、目標はできるだけ警告を少なくすることであり、チームが問題を解決するために即座に行動を起こすことができるイベントに対してのみであるべきであるということです。 アラートが多すぎる、または実際には修正できない状況に対するアラートは、アラート疲労につながる可能性があります。 この倦怠感は、がクリティカルで実行可能であるというアラートを見逃したり無視したりする可能性のある不幸な従業員をもたらす可能性があります。

SREブックには、アラートを設定する際に留意すべきいくつかの原則がまとめられています：

  • ポケットベルが消えるたびに、私は切迫感を持って対応できるはずです。 倦怠感を感じる前に、私は一日に数回しか切迫感に反応することができません。
  • すべてのページが実用的である必要があります。
  • すべてのページ応答にはインテリジェンスが必要です。 ページが単にロボットの応答に値する場合、それはページであってはなりません。
  • ページは、これまでに見たことのない新しい問題やイベントに関するものでなければなりません。

アラートがこれらの基準を満たしていない場合は、優先度の低いチケットシステムまたはログファイルにアラートを送信するか、アラートを完全に削除することをお勧めします。

一部のオープンソースの監視およびアラートシステムの設定の詳細については、以下の関連チュートリアルを参照してください。

関連チュートリアル：

2. ソフトウェア展開の改善

ダウンタイムに影響を与える可能性のあるもう1つの領域は、ソフトウェアの展開戦略です。 デプロイプロセスを完了するために複数の手動ステップが必要な場合、またはその他の方法で複雑すぎる場合、本番環境は開発環境よりも大幅に遅れる可能性があります。 これは、各展開がより多くの潜在的な複雑さを伴うはるかに大きな変更のセットになるため、よりリスクの高いソフトウェアリリースにつながる可能性があります。 これにより、バグが発生し、開発速度が低下し、劣化したサービスや利用できないサービスが意図せずに展開される可能性があります。

展開をスムーズにするためには、事前の時間と計画が必要ですが、最終的には、コードの統合、テスト、および展開のワークフローを自動化できる戦略を考え出すことで、より緊密な本番環境につながります。開発と一致します—より頻繁なデプロイとリリース間のより少ない複雑さで。

CI/CDのベストプラクティス

現在利用可能なコンテナテクノロジ、構成管理ソフトウェア、プログラミング言語、およびオペレーティングシステムの多様性により、展開を自動化する方法の具体的な詳細は、どの記事の範囲も超えています。 一般に、開始するのに適した場所は、継続的インテグレーション（CI）配信（CD）とソフトウェアのテストに関するベストプラクティスに従っていることを確認することです。 これらのベストプラクティスには、次のものがあります。

  • 単一のリポジトリを維持する：全員が定期的にコードを同じリポジトリに統合する必要があります。このリポジトリには、比較的ベアマシンまたはCI環境でプロジェクトをビルドするために必要なすべて（テストおよび構成ファイルを含む）が含まれている必要があります。 これにより、誰もが同様のコードベースで作業し、統合が比較的簡単になり、誰もが変更を簡単にテストおよび構築できるようになります。
  • テストとビルドの自動化： CIソフトウェアまたはサービスは、テストを自動的に実行してプロジェクトをビルドできる必要があります。
  • デプロイの自動化： CIソフトウェアは、最終的な本番環境を厳密にシミュレートするテスト環境でビルドをデプロイおよびテストできる必要があります。

これらのプラクティスは、継続的インテグレーションとデリバリー環境を説明していますが、本番環境へのデプロイに至るまでは至っていません。 自動テストに十分な自信があれば、本番環境へのデプロイを快適に自動化できる可能性があります。 または、これを手動タスク（または、開始するために人間の判断を必要とする自動タスク）にすることを選択することもできます。

いずれにせよ、ユーザーにダウンタイムを発生させることなく、新しいバージョンを本番環境にプッシュする方法が必要になります。 インフラストラクチャの更新中にサービスの中断が発生した場合、頻繁な展開は大きな不便になります。

青緑色の展開

バージョン間のシームレスなカットオーバーを使用して、本番環境への安全な最終プッシュを実装する1つの特定の方法は、青緑展開と呼ばれます。

青緑色の展開では、2つの間でトラフィックを簡単に切り替えることができるメカニズムの背後に2つの同一の本番環境をセットアップする必要があります。 このメカニズムは、青または緑のサーバー間ですばやく切り替えることができるフローティングIP アドレス、または複数のサーバーのクラスター全体を切り替えるためのロードバランサーである可能性があります。

どの時点でも、環境の1つ（この場合は青など）のみが稼働しており、本番トラフィックを受信しています。 新しいバージョンをリリースするプロセスは次のとおりです。

  • ビルドを非アクティブな環境（この例では緑色）にプッシュします。
  • この実稼働環境でビルドをテストします。
  • すべてのテストに合格したら、ロードバランサーの構成を更新するか、フローティングIPをグリーンサーバーに割り当てることで、トラフィックをグリーン環境にカットします。

この手法には、問題が発生した場合に以前のバージョンにロールバックするための単純なメカニズムを提供するという追加の利点があります。 新しいリリースに慣れるまで、以前のデプロイを稼働状態に保ちます。 ロールバックが必要な場合は、ロードバランサーまたはフローティングIPを再度更新して、前の状態に戻します。

繰り返しになりますが、安全でフォールトトレラントな方法でデプロイプロセスを自動化するという目標を達成する方法はたくさんあります。 ここでは、1つの可能性のみを強調しました。 以下の関連チュートリアルには、オープンソースCI/CDソフトウェアと青緑色の展開に関する詳細情報があります。

関連チュートリアル：

3. 高可用性の実装

ダウンタイムを最小限に抑えるための最後の戦略の1つは、高可用性の概念をインフラストラクチャに適用することです。 高可用性という用語は、冗長で復元力のあるシステムを設計するためのいくつかの原則を要約したものです。 これらのシステムは通常、次のことを行う必要があります。

  • 単一障害点の排除：これは通常、複数の冗長サーバーまたは冗長コンテナ化されたサービスを意味します。 また、複数の地域の複数のデータセンター間でインフラストラクチャを分散させる可能性も検討されています。 これらのボトルネックを解消するためにどの程度深く取り組むかは、コストと複雑さに対する許容度、および組織とユーザーのニーズによって異なります。 たとえば、すべてのサービスに冗長ロードバランサーとリージョン間の自動フェイルオーバーが必要になるわけではありません。
  • トラフィックをシームレスにリダイレクト：ダウンタイムを最小限に抑えるには、サーバー間のトラフィックを迅速に削減し、サービスの中断を最小限に抑える必要があります。
  • 冗長システムの状態を検出する：トラフィックをいつ再ルーティングするかを決定するために、システムはサービスが失敗したときを判断できる必要があります。

ロードバランサーを使用したWebサーバーのアップグレード

より可用性の高いインフラストラクチャにアップグレードする1つの例は、単一のWebサーバーから複数のWebサーバーとロードバランサーに移行することです。 ロードバランサーは、Webサーバーで定期的なヘルスチェックを実行し、障害が発生しているサーバーからトラフィックをルーティングします。 このインフラストラクチャは、前のセクションで説明したように、よりシームレスなコード展開を可能にすることもできます。

データベースの復元力の向上

復元力と冗長性を追加するもう1つの例は、データベースレプリケーションです。 たとえば、MySQLデータベースサーバーには、さまざまなレプリケーション構成があります。 グループレプリケーションは、サーバーの冗長クラスターで読み取り操作と書き込み操作の両方を有効にするという点で興味深いものです。 ダウンタイムに対して脆弱な単一のサーバーにすべてのデータを配置する代わりに、複数のサーバー間で複製することができます。 MySQLは、障害のあるサーバーを自動的に検出し、問題を回避します。

CockroachDB などの新しいデータベースは、これらの冗長レプリケーション機能を念頭に置いてゼロから構築されており、複数のデータセンターの複数のマシン間で高可用性データベースアクセスをすぐに利用できます。

フローティングIPとホットスペアサーバーの使用

高可用性アーキテクチャの最後の例は、フローティングIP を使用して、ホットスペアサーバーにトラフィックをフェイルオーバーすることです。 多くのクラウドプロバイダーには特別なIPアドレスがあり、APIを使用してさまざまなサーバーやロードバランサーにすばやく再割り当てできます。 ホットスペアは、いつでも使用できる冗長サーバーですが、プライマリサーバーがヘルスチェックに失敗するまでトラフィックを受信しません。 その時点で、フローティングIPがホットスペアに再割り当てされ、トラフィックがそれに続きます。 これらのヘルスチェックとフローティングIPAPI呼び出しを実装するには、keepalivedやheartbeatなどの追加のソフトウェアをインストールして構成する必要があります。

以下の関連チュートリアルでは、インフラストラクチャの復元力を高めるために使用できるその他のソフトウェアとツールに焦点を当てています。

関連チュートリアル：

結論

この記事では、プロセスまたはインフラストラクチャの改善により、ダウンタイムの短縮、売上の増加、ユーザーの満足度の向上につながる可能性のある3つの領域を確認しました。 指標の監視、展開の改善、インフラストラクチャの可用性の向上は、アプリやサービスをより本番環境に対応し、復元力を高めるために実装できる変更の調査を開始するのに適した場所です。

もちろん、信頼性には、これら3つのポイントだけではありません。 詳細については、各セクションの最後にある推奨チュートリアルを詳しく調べ、無料オンラインで入手できるサイト信頼性エンジニアリングの本を確認してください。