前書き

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

利用できないウェブサイト、API、またはその他のサービスは、販売の損失に起因する大きな金銭的コストを伴う場合があります。 さらに、ダウンタイムは以下につながる可能性があります。

  • *不幸な顧客とユーザー:*ユーザーは安定したサービスを期待しています。 中断すると、サポートリクエストが増え、ブランドに対する一般的な信頼が失われる可能性があります。

  • *生産性の低下:*従業員が仕事をするためにサービスに依存している場合、ダウンタイムは組織の生産性の損失を意味します。 また、従業員がサーバーの再起動とダウンタイムとの戦いに時間を費やしている場合、彼らは新しい機能や製品を開発していません。

  • *不幸な従業員:*頻繁なダウンタイムアラートはアラートの疲労につながり、問題を解決するために絶えずスクランブルをかけると、チームとその士気に打撃を与える可能性があります。

これらの問題に対処するために統合された現代のフィールドは、Site Reliability Engineering_またはSREと呼ばれます。 SREは2003年にGoogleで作成され、彼らが開発した戦略はhttps://landing.google.com/sre/book.html[_Site Reliability Engineering]という本にまとめられました。 このフィールドを読むことは、ダウンタイムを最小限に抑えるためのテクニックとベストプラクティスを検討するのに適した方法です。

この記事では、改善により組織のダウンタイムを削減できる3つの領域について説明します。 これらの領域は、* link:#1-監視と警告[監視と警告] link:#2-改善ソフトウェア展開[ソフトウェア展開] 、および link:#3-実装高可用性です。 [高可用性] *。

これは戦略の完全なリストではありませんが、サービスの生産準備を改善するときに考慮する必要がある一般的なソリューションを示すことを目的としています。

[[1-monitoring-and-alerting]]
=== 1. 監視と警告

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

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

  • * https://prometheus.io/ [Prometheus] *は、さまざまな公式およびコミュニティがサポートするクライアント(_exporters_と呼ばれる)からデータをプルできます。 非常にスケーラブルで、アラート機能が組み込まれており、ほとんどのプログラミング言語で利用可能なクライアントライブラリがあります。

  • * https://graphiteapp.org/ [Graphite] *は、多数のプログラミング言語とアプリケーションでサポートされる、今やユビキタスなAPIを提供します。 メトリックは、ノードから中央のGraphiteインストールにプッシュされ、そこで保存およびグラフ化されます。

また、ログファイルを中央サービスにプッシュし、例外やエラー率などの関連するメトリックのためにログファイルを解析することも一般的です。 Elastic stack(Elasticsearch、Logstash、Kibana)およびhttps://www.graylog.org/[Graylog]は、ログファイルの解析と分析を容易にするソフトウェアスタックの例です。

メトリックの視覚化

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

アラートを設定する

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

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

覚えておくべき主なことは、目標は可能な限り警告を少なくすることであり、チームが問題を解決するために即座に対応できるイベントに対してのみであることです。 アラートが多すぎる、または実際には修正できない状況のアラートは、_アラート疲労_につながる可能性があります。 この疲労により、従業員は不幸であり、重要かつ実行可能なアラートを逃したり無視したりする可能性があります。

_
* ページャーがオフになるたびに、私は切迫感に反応できるはずです。 疲労感を感じる前に、一日に数回、切迫感に反応することができます。
* すべてのページは実用的でなければなりません。
* すべてのページ応答にはインテリジェンスが必要です。 ページが単にロボットの反応に値する場合は、ページであってはなりません。
* ページは、新しい問題またはこれまでに見たことのないイベントに関するものでなければなりません。
_

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

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

関連チュートリアル:

[[2-improving-software-deployments]]
=== 2. ソフトウェア展開の改善

ダウンタイムに影響を与える可能性がある別の領域は、ソフトウェアの展開戦略です。 展開プロセスが完了するために複数の手動手順を必要とする場合、またはそうでなければ過度に複雑になる場合、実稼働環境は開発環境から大幅に遅れる可能性があります。 これにより、各デプロイがより大きな変更セットになり、より複雑な可能性があるため、ソフトウェアリリースがよりリスクの高いものになる可能性があります。 これにより、バグが発生し、開発速度が低下し、劣化したサービスや利用できないサービスが意図せずに展開される可能性があります。

展開をスムーズにするには事前の時間と計画が必要になりますが、最終的には、コードの統合、テスト、および展開のワークフローを自動化できる戦略を考え出すことで、より緊密に運用環境を構築できます。開発に匹敵します-より頻繁な展開とリリース間の複雑さの減少。

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

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

  • *単一のリポジトリを維持する:*比較的裸のマシンまたはCI環境でプロジェクトをビルドするために必要なすべてのもの(テストファイルと構成ファイルを含む)を含む必要があるすべての人が定期的にコードを同じリポジトリに統合する必要があります。 これにより、すべての人が同様のコードベースで作業し、統合が比較的簡単になり、誰でも簡単に変更をテストおよび構築できます。

  • テストとビルドの自動化: CIソフトウェアまたはサービスは、テストを自動的に実行してプロジェクトをビルドできる必要があります。

  • 展開の自動化: CIソフトウェアは、最終的な本番環境を厳密にシミュレートするテスト環境でビルドを展開およびテストできる必要があります。

これらのプラクティスは、継続的な統合および配信環境について説明していますが、本番環境に至るまでの道のりはありません。 自動化されたテストに十分な自信があれば、本番環境への展開を自動化することができます。 または、これを手動タスク(または、開始するには人間の判断が必要な自動タスク)にすることもできます。

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

ブルーグリーン展開

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

青緑展開では、2つの間でトラフィックを簡単に切り替えることができるメカニズムの背後に、2つの同一の実稼働環境をセットアップする必要があります。 このメカニズムはhttps://www.digitalocean.com/community/tutorials/how-to-use-floating-ips-on-digitalocean[floating IP]アドレスであり、青または緑のサーバー間で迅速に切り替えることができます。複数サーバーのクラスター全体を切り替えるためのロードバランサー。

いずれの時点でも、稼働している実稼働トラフィックを受信して​​いる環境は1つだけです(この場合は青だとしましょう)。 新しいバージョンをリリースするプロセスは次のとおりです。

  • ビルドを非アクティブ環境にプッシュします(この例では緑)。

  • この実稼働環境でビルドをテストします。

  • すべてのテストに合格したら、ロードバランサーの構成を更新するか、フローティングIPをグリーンサーバーに割り当てることにより、トラフィックをグリーン環境にカットします。

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

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

関連チュートリアル:

[[3-implementing-high-availability]]
=== 3. 高可用性の実装

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

  • *単一障害点の排除:*これは通常、複数の冗長サーバーまたは冗長コンテナ化サービスを意味します。 また、複数の地域の複数のデータセンター間でインフラストラクチャを拡散する可能性も検討されています。 これらのボトルネックをどれだけ深く除去するかは、コストと複雑さに対する許容度、および組織とユーザーのニーズによって異なります。 たとえば、すべてのサービスに冗長ロードバランサーやリージョン間の自動フェールオーバーが必要なわけではありません。

  • *シームレスなトラフィックのリダイレクト:*ダウンタイムを最小限に抑えるには、サーバー間のトラフィックを迅速に削減し、サービスの中断を最小限に抑える必要があります。

  • *冗長システムの正常性を検出:*トラフィックをいつ再ルーティングするかの決定を通知するために、システムはサービスがいつ失敗するかを決定できなければなりません。

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

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

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

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

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

高可用性アーキテクチャの最後の1つの例は、https://www.digitalocean.com/community/tutorials/how-to-use-floating-ips-on-digitalocean [floating IPs]を使用して、_hot spare_サーバーにトラフィックをフェイルオーバーすることです。 。 多くのクラウドプロバイダーには、APIを使用して異なるサーバーまたはロードバランサーにすばやく再割り当てできる特別なIPアドレスがあります。 ホットスペアは常に準備ができている冗長サーバーですが、プライマリサーバーがヘルスチェックに失敗するまでトラフィックを受信しません。 その時点で、フローティングIPがホットスペアに再割り当てされ、トラフィックがそれに続きます。 これらのヘルスチェックとフローティングIP API呼び出しを実装するには、https://www.digitalocean.com/community/tutorials/how-to-set-up-highly-などの追加のソフトウェアをインストールして構成する必要があります。 available-web-servers-with-keepalived-and-floating-ips-on-ubuntu-14-04 [keepalived]またはhttps://www.digitalocean.com/community/tutorials/how-to-create-a-high -ハートビートとフローティングIPを使用したubuntu-14-04を使用した可用性のセットアップ[ハートビート]。

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

関連チュートリアル:

結論

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

もちろん、これら3つのポイント以外にも信頼性があります。 詳細については、各セクションの最後にある推奨チュートリアルをさらに掘り下げ、https://landing.google.com/sre/book.htmlである_Site Reliability Engineering_ bookをご覧ください。 ]。