Work ideas for stability and high availability assurance

安定性と高可用性に関する深い理解

安定性と高可用性は、よく耳にする言葉です。経験や感覚から、これらの指標を向上させればシステムが健全になり、プロダクトのユーザー体験が向上することは分かっています。しかし、安定性と高可用性の定義を求められたら、どのように表現すればよいでしょうか。安定性と高可用性の違いと関連性は何でしょうか。まずこの 2 つの課題を理解してから、明確な目標を設定し、完全かつ実行可能な計画を体系的に策定する必要があります。

Wikipedia で安定性を検索すると、次のように定義されています。

安定性とは、システムが有界入力に対して有界出力を生成するかどうかを判定する数学または工学の用語です。条件を満たす場合、システムは安定と呼び、満たさない場合は不安定と呼びます。
次に高可用性を見てみましょう。

高可用性（英：high availability、略称 HA）は IT 用語であり、システムが中断なくその機能を実行する能力を指し、システムの可用性の程度を表します。これはシステム設計の基準の一つです。高可用性のシステムは、システムを構成する個々のコンポーネントよりも長い期間にわたって稼働できます。

まず安定性の定義からキーワードを抽出します -- システム、入力、出力。Ant の現在の技術アーキテクチャでは、アプリケーションはシステムと見なせ、アプリケーション間のサービスリクエストが入力、サービス応答が出力となります。サービス応答が期待通りである場合、アプリケーションシステムは安定していると判断されます。これらが組み合わさってより大きなシステムを形成し、ビジネスプロダクトとしてユーザーに提供される場合、ユーザーのリクエストが入力となり、プロダクトの表現が出力となります。プロダクト機能が正常に動作している場合、プロダクトシステムは安定していると見なせます。まとめると、安定性の定義は次のように要約できます -- システムが入力を受け取ったとき、正しく期待通りの出力を生成できれば、そのシステムは安定と呼び、そうでなければ不安定と呼びます。

本題に戻りましょう。なぜ「安定性保証」と呼ぶのでしょうか。「安定性向上」という表現に変えられないでしょうか。上記の定義から、安定性はシステムの動作を記述するものであるという結論が得られます。システムが安定しているかどうかは、人の健康状態を評価するのと同様に、一つの文章で記述・定量化することは困難です。しかし、否定的な方法であれば素早く判断できます。人々は病気の発生を減らし、良好な健康状態を維持するために、適切な食事や生活習慣を取り入れます。システムの安定性確保や安定性向上も同様です。さまざまな方法を使用して、不安定な状況を回避する必要があります。いわゆる「より安定」というのは客観的に存在するものではなく、主観的に不安定の発生を回避または軽減したいという願望です。

安定性と異なり、可用性は定量化可能な指標であり、計算式は Wikipedia で次のように記述されています。

システムの損傷、利用不能時間、および運転不能状態から運転可能状態への回復時間を、総システム稼働時間と比較したものです。

よく耳にするスリーナイン（99.9%）やフォーナイン（99.99%）は、システムの可用性を測定するものです。高可用性とは、この指標を高いレベルで維持することを保証します。計算式の定義説明では、システムの稼働時間は 3 つの部分に分類されます。

システムが正常に動作している時間、つまりシステムが安定状態にある時間。
システムが損傷または利用不能になっている時間、つまりシステムが不安定状態にある時間。
システムが運転不能状態から運転可能状態へ回復するのにかかった時間、つまりシステムが不安定状態から安定状態へ回復するのにかかった時間。
システムの可用性とシステムの安定性は正の相関関係にあります。しかし、現実の世界では、システムが永遠に安定状態を維持することはできません。逆方向から考えて上記の式を変換すると、分析により適した形になります。

image.png

以上より、この課題の目標、KPI が明確になりました。システムの安定性と高可用性を確保する目標は、システムを安定した動作状態に保ち、ユーザーに悪影響を与えず、オンライン問題や P レベルの障害を回避することです。コア KPI はシステムの可用性です。システムの可用性を向上させるためには、まずシステムの安定性を確保し、不安定状態の発生を減らす必要があります。次に、さまざまなコンポーネントの障害によりシステムが不安定状態になった場合、迅速に検出して安定した利用可能な状態に復旧させる必要があります。

安定性と高可用性保証の 2 つのコアアイデア

上記の推論を通じて、システム可用性向上の目標に対する 2 つの基本的な問題解決アプローチが得られます。図によると、問題を解決するためには、まず問題を見つけて定義することが最初のタスクです。したがって、システムの安定性を向上させるためには、まずアプリケーションシステムで一般的な不安定状況を列挙し、一つずつ適切な対策を講じます。

機能性：アプリケーションが期待通りでない機能でエラーを実行した場合。

容量：システムが受け取るリクエスト数が増加したとき、アプリケーションを正常に処理できず、例外やタイムアウトが発生し、サービス障害につながる場合。

セキュリティ：システムが許可されていないリクエストや悪意のある攻撃リクエストを受けたとき、アプリケーションが異常を起こしたり、サービスが障害を起こしたりする場合。

フォールトトレランス：アプリケーションが使用上のユーザーエラーを適切に処理できない場合。

上記の状況が発生した場合、システムは不安定状態にあることを意味し、タイムリーに検出および対処できる必要があります。これらの問題の原因は通常、ソフトウェアシステムにおいて次の 3 つのカテゴリに分類できます。

人為的障害：ソフトウェア開発のさまざまな段階での考慮不足、または不注意な実行によるさまざまな問題。

ハードウェア障害：ネットワーク障害、ディスク領域不足、メモリクラッシュなど。

ソフトウェア障害：スレッドプール例外、JVM 例外、ミドルウェアまたは他の依存アプリケーションサービスの例外。
動的に進化するシステムとして、障害の発生確率を 0 に下げる方法はありません。ソフトウェア生産の過程でプロセス仕様とメカニズムを確立することで、その発生を最小限に抑えることしかできません。次に、稼働中のシステムに対して、モニタリングと早期警告メカニズムを確立・改善し、システム内の障害をタイムリーに検出し、計画の実装を通じてシステムを迅速に復旧させる必要があります。上記の結論に基づき、システムの可用性を向上させるためには、次の 3 つの側面から取り組む必要があります。障害予防、障害検知、および障害復旧です。


人間が誤りを犯す確率は機械よりもはるかに高いため、障害予防にとって最も重要なのはメカニズムを確立し、チーム内で合意を形成し、このプロセスに従って継続的に研究開発作業を進めることです。これにより、個人的要因（思考、実行、状態など）がシステムの安定性に与える影響を軽減します。障害検知と障害復旧については、システムモニタリングと緊急対応ソリューションを通じてシステムの異常を迅速に検出し復旧させることで、障害の影響を最小限に抑える必要があります。Ant の日常プロダクト開発プロセスを例として、機能、容量、セキュリティ、フォールトトレランスの 4 つのコア要素から出発し、一連のソリューションを提示します。参考までに。

1 研究開発仕様

設計フェーズ

*チーム分割ドキュメントテンプレート
* 高可用性設計仕様
*コーディング段階

コード仕様

1. 一般コード仕様
2. 工学構造仕様

単体テストカバレッジ

*単体テスト合格率
* コードカバレッジ
*ログ仕様
*セキュリティ脆弱性修正仕様
* リリースフェーズ

変更仕様：三板斧

2 容量保証
容量評価

*マシン容量
*DB 容量
*キャッシュ容量
*負荷テスト
*レート制限スキーム
*縮退計画

3 モニタリングアラーム

ログ仕様
モニタリング整理

アプリケーション基本モニタリング
*ゲートウェイモニタリング
*サービス監視
*ビジネスモニタリング
* レート制限モニタリング
*アラーム仕様
*データチェック

4 緊急対応

日常計画

*ハードウェア例外計画
*ミドルウェア例外計画
*ビジネス例外計画
*プロモーション計画
*計画実行仕様

3 まとめ

安定性と高可用性をどのように確保するかは巨大な課題であり、内容のどんな小さな部分についても、イントラネットで大量の記事を検索できます。この記事を書く目的は、安定性と高可用性の保証作業に対する私の理解をまとめ、一連のシステムフレームワークのアイデアを共有することです。この本を読んだ後、すべての人が詳細に立ち止まることなく、安全な生産についてより包括的な理解を持てることを願っています。