Four steps to landing stability guarantee work

安定性とは何か。安定性という言葉と初めて出会ったのは、Alibaba に入社して最初のダブルイレブンの KO ミーティングだった。
カレント制限、キャパシティ拡張、負荷テストといった用語に触れたとき、安定性保証の作業は些末で煩雑、プロセスも明確な測定指標もなく、どこから手をつければよいかわからないと感じた。今年、2人の仲間と協力して安定性保証作業に多くの時間を費やした。
彼らから安定性保証に関する多くの知識を学び、安定性の作業について一定の理解を持つようになった。安定性の作業も組織的かつ段階的だ。
手順に従って進めれば、安定性保証作業を確実に完了し、正しく、そして適切に実行できる。百聞は一見に如かず、百見は一筆に如かず。
この機会に整理して記録し、後から参照しやすくしておく。安定性保証とは何か。
では、安定性保証とは具体的に何を指すのか。これまでの知見によると、安定性保証とはシステムの安定性を確保し、予測不可能な状況下でも継続的かつ安定的に稼働し、サービスを提供し続けることだ。
個人的には、安定性保証は水利事業に非常に似ていると感じる。アプリケーションシステムにおける「水」はユーザーフローまたは資金フローであり、安定性の作業は、水が定められた経路に沿って流れるようにし、浸水、漏水、経路崩壊が発生しないようにすること、あるいはそのような現象が発生した際に速やかに修復して損失を最小限に抑えることだ。
安定性保証は何をするのか。安定性保証は具体的に何をするのか。
もちろん、安定性保証の目標を達成することだ。前述の安定性保証の定義から、「予測不可能な状況下での継続的な安定稼働とサービス提供」が安定性保証作業の目標であることがわかる。
この目標をどう達成するか。まだ漠然としていて、どこから手をつければよいかわからない。
それは目標が大きすぎて漠然としているからだ。大きく漠然とした目標に直面したときは、目標細分化の分割統治法を用いる。
下図の赤い破線矢印で示された手順が必要だ。まず、目標をサブゴールに細分化する。
サブゴールは目標からキーワードを抽出して定義できる。「予測不可能な状況下での継続的な安定稼働とサービス提供」から、「予測不可能」「発生時」「継続的安定性」「稼働」「サービス提供」の5つのキーワードを抽出できる。
これら5つのキーワードが安定性保証作業のサブゴールだ。次に、各サブゴールに対して疑問点をすべて洗い出す。
目標の理解に関する疑問、実現方法に関する疑問、実現基準に関する疑問など、あらゆる疑問を列挙する。その後、すべての疑問に対する答えや解決策を見つける。
それは学校のときに指導教官からテーマを与えられ、自分で理解して解決していくプロセスに似ている。データ調査、現状分析、方案選定、最終的な意思決定、実際の施行が必要になる場合がある。
こうして各サブゴールを一つずつ達成し、最終的にサブゴールの実現によって最終目標の全体実現を達成する。まとめると、上図の外側の薄い青い円の内容が、安定性保証の目標を達成するために必要な作業だ。
一見すると多く見えるが、よく見ると隠れたパターンがある。さらに詳しく見ると、本質的には次のポイントだ。
どんな現象が起きたか。どうやって発見するか。
どんな影響があるか。どう対処するか。
現象、影響、対処方法はすべて特定の異常と結びついており、検知は監視とアラームに依存する。まとめると、異常事態の整理 → モニタリングアラームの設定 → 影響面の評価 → 解決策の計画。
次に、この4つのステップから安定性保証作業の具体的な実装方法を説明する。まず大きなフレームワークを下図に示す。
異常事態の整理。では、異常事態とは何か。
RT の上昇、メッセージキューのブロック、FullGC、NPE、データ例外、データ不整合、資金額計算エラー、データベース接続タイムアウト、ネットワーク例外、コードバグによる例外など、非常に多くの異常状況がある。これほど多くの項目をどう整理してカバレッジを確保するか。
前述の目標細分化の分割統治法を引き続き用いるが、この段階ではキーワードの分割では細分化できない。カテゴリ別の細分化でサブ目標を定義できる。
例外を分類する。上記の例外から分類を行うと、メッセージキュー、データベース接続、FullGC はミドルウェアに起因する例外であり、コードバグ、データ不整合、資金額計算エラーは開発者が書いたバグまたはプロダクト設計の欠陥であることがわかる。
まとめると、ミドルウェア関連の例外を「インフラ例外」、バグやプロダクト欠陥などの例外を「業務機能例外」と定義できる。逆に整理すると、インフラ例外にはネットワーク、キャパシティ、接続、ディスク、キャッシュ、JVM およびその他のミドルウェアまたは基盤ハードウェア施設が含まれる。
このような例外は通常日常的には発生せず、大規模かつ突発的なトラフィック変動時にインフラが過大なトラフィックを処理しきれなくなって初めて発生する。したがって、主にプロモーション期間中に発生する。
業務機能例外にはコードロジック例外と資金例外が含まれる。ビジネス機能と密接に関連しているため、このような例外は一般的にビジネスロジックの各変更後に現れ、日常のニーズに対応する。
各業務要件の開発と同時に整理し、異常整理の結果に基づいてスイッチや修正ツールを事前にコードに組み込んでおける。本番環境で異常が発生した場合、プリセットのスイッチと修正ツールで止血や修復を行える。
ちなみに、例外の分類に基づき、安定性保証作業は日常的な安定性保証と大規模プロモーション安定性保証に分類される。日常的な安定性保証は主に業務機能の異常を対象とする。
この種の安定性保証作業は各業務要件の開発と並行して実施され、リリースは必ずビジネス機能のリリースより先に行う。日常的なビジネス機能の変更ではインフラ異常は通常発生しないため、日常的な安定性保証でインフラ保証を扱うことは稀だ。
大規模プロモーション安定性保証は主にインフラ異常を対象とする。大規模プロモーションによりトラフィックが数十倍、数百倍、場合によっては数千倍に増加し、インフラは巨大な負荷に直面してさまざまな異常が発生する。
大規模プロモーション安定性保証作業は、各プロモーション開始前に完了させる必要がある。モニタリングアラームの設定。
監視アラームはインフラ監視アラーム、業務機能モニタリングアラーム、資金セキュリティモニタリングアラームの3種類に分類される。インフラ監視アラームは一般的にアプリケーション作成時に初期設定され、アプリケーションとすべてのミドルウェア、ネットワークをカバーする。
グループ内では基本監視アラームのカバレッジについて明確な規定がある。業務機能モニタリングアラームは開発者が日常の業務機能開発時に特定のビジネスシナリオを監視するために設定する。
資金セキュリティモニタリングアラームは主に注文や決済などの資金関連アプリケーションを対象とする。存在しない場合はゼロから作成し、その後は各業務機能の開発に合わせて段階的に設定する。
大規模プロモーション前には、すべての監視アラームを整理して漏れを確認し、ギャップを埋める。データフロー図。
監視アラーム設定は実際には省略表現で、完全な表現は「監視アラームデータソースの準備、監視アラーム設定」となる。監視アラームの全体的なデータフローは上図の通りだ。
主にログ、メッセージ、永続データをデータソースとして利用し、データを収集して監視アラーム設定に活用する。そのうち、ログは主にマーケット表示の監視に使用され、リアルタイムでオンラインの状況に即応する。
メッセージは主にリアルタイム検証のトリガー媒体として使用され、資金セキュリティチェックを発動させる。資金セキュリティチェックではバイパスチェック、資金整合性チェック、ペアワイズチェックなどの方法でオンラインロジックを検証する。
永続データは主にオフラインチェックに使用され、ペアワイズチェックでデータの正確性を検証する。具体的なチェックロジックは後述する。
最後に、監視とチェックはアラーム情報をアラームシステムに集約してアラームを発生させ、アラーム対応者に同期して処理させる。設定手順。
まとめると、監視アラームのデータソースとフロー方向を理解したら、次の手順で監視アラームを設定できる。注目すべきは、データがあって初めて監視を設定できるが、実際にはデータ準備と監視設定は並行して行うべきだということだ。
監視項目の全体計画に基づいて監視データを準備し、その後監視アラームを設定する。データが設定要件を満たさない場合は、データ準備ステップに戻る。
個人的には、監視システムの品質は主に正確性、カバレッジ、直感性の3つの指標で判断されると考える。正確性は監視の基本機能を保証し、実際の状況を正しく反映する。
正確性のない監視には意味がない。カバレッジは監視システムの成否を測る重要な指標だ。
カバレッジが高いほど、監視システムは実際の稼働状況をより完璧に反映できる。直感的な監視指標の表示は異常の早期発見と問題の迅速な特定に役立つ。
アラームについては、アラーム設定で最も重要な3つの要素は適時性、有効性、責任性だと考える。アラームの発生は一般的に異常状況を示し、資金損失や機能不全に関わる可能性がある。
発見が早ければ早いほど止血も早くなり、損失も少なくなる。アラームは最終的に人手で処理されるため、無効なアラームは人的コストを浪費する。
したがって、アラーム設定ではノイズのフィルタリングに注力し、アラームの有効性を確保して報告される問題が実際の課題であることを保証する必要がある。責任制については、すべてのアラームに誰かが対応しなければならず、各アラームを特定の担当者に割り当てることが最適だ。
対応可能なアラームこそが最終的で効果的なアラームだ。資金セキュリティチェック。
資金セキュリティチェックの本質は、資金損失事象の有無を確認し、適時にアラームを発して迅速に止血し、最終的に資金損失の防止と制御を実現することだ。資金ロジックには一般のビジネスロジックと共通する特徴があるため、これらの共通点に基づいて共通の資金セキュリティチェック方法と資産損失防止・制御措置を考案できる。
資金セキュリティチェックの方法論について、先人のまとめによると、資金セキュリティ上の問題は主に資金のキーエレメントの処理過程で生じる異常に起因する。資金のキーエレメントのライフサイクルには主に生産、配送、消費の3つの重要なノードがある。
3つのノードで発生しうるエラーは、生産エラー、送信漏れ・誤送信、消費エラーだ。これらのエラーに対応して、先人は3つの主要な検証方法を提案した。
検証とは、正しいデータを期待値として用意し、実際の状況を期待データと比較して確認することだ。ベースラインチェックは履歴データを期待値として比較検証する。
この方法は履歴データの正確性に依存し、必要な投資は少なく、有効性は低いが、大規模な資金問題を発見できる。ツーツーチェックは上流を期待値として比較検証を行う。
精度と適時性が高いが、コストも比較的高く、包括的なカバーは難しい。業務ロジックチェックは業務専門家の経験を期待値として活用する。
人的投資が大きく経験への依存度が高いが、精度と適時性に優れている。資産損失防止・制御に関して、どのような具体的な措置を採用できるか。
資産損失防止・制御を専門とする仲間が非常に包括的なまとめを作成した。下図に示す通り、資産損失防止・制御の戦略には、保有量の維持、ディスク増分の管理、高リスク管理、一意性がある。
資産損失防止・制御は長期的なプロセスで、頻繁なメンテナンスが必要だ。既存配置の維持と管理を継続的に最適化し、新しい変更に対して資金損失評価を実施し、リリース前にチェックポイントを確認して対応する検証ルールを確保する。
脆弱な損失シナリオとデータに対して特別な再検証を行い、大規模プロモーション固有のロジックやシーンに特に注意を払う。資産損失を防止・制御するには、全リンクの資金セキュリティリスクシナリオを整理し、出血タイプ、ルール式、ルールタイプ、依存要因などのさまざまな観点から資金損失シナリオを分析し、対応する出血モデルを構築する必要がある。
高速かつ正確な対応を確保するため、非同期メッセージを監視してリアルタイム検証を行い、特定のエラーログアラームと組み合わせ、時間単位のオフライン永続データ検証を連携させて資金の安全性を保証する。検証スクリプトの正確性は、組織的なレビューと攻防検証を通じて保証できる。
資金損失マーケットを設置し、大規模プロモーションのピーク期間には専門人員を配置してマーケットを監視し、問題にタイムリーに対応する。同時に、資金損失リスクが高い項目に対しては必要な緊急予案を事前に設定しておく。
影響面の評価。影響面も当然異常と関連している。
インフラの異常には多くの種類がある。短期間の高負荷といった軽微なものから、特定ミドルウェア（MetaQ など）の利用停止、データセンターの停電、光ケーブルの切断といった深刻なものまである。
異常の深刻度が影響面を直接決定する。エラー率の急上昇、RT の急上昇、メッセージのブロック、FullGC の頻発などがシステムの継続的な安定性に影響を与える可能性がある。
さらに深刻な場合はシステムが麻痺して利用不能になり、ネットワークが使用できなくなり、トラフィックがゼロになることもある。ただし、そのような深刻な異常は通常発生しない。
データセンターは複数拠点に分散配置され、ハードウェアのディザスタリカバリは専門チームが保証している。ミドルウェアについても、専門チームによる運用・メンテナンスが必要だ。
安定性保証作業では、インフラ異常について通常考慮するのは、大規模なトラフィック急増によるキャパシティ不足とシステム高負荷の問題だけだ。この種の問題の原因は明確で、トラフィックが大きすぎることだ。即座に現れる現象は、エラー率の急上昇、RT の急上昇、メッセージのブロック、FullGC の頻発などだ。より深刻な場合は顧客クレームや世論問題を引き起こす。業務機能の異常はエラーだ。ロジック異常、資金計算エラー、資金フローエラーのいずれであっても、本質的にはプロダクト設計の不足、開発が残したバグ、またはどこかの設定ミスだ。この種の異常は特定の業務シナリオに関連し、小規模なものはローカルの小機能にのみ影響するが、大規模なものはコア機能に影響する。顧客クレームや世論問題を引き起こす可能性があり、異常な資金は資金損失につながる恐れがある。解決策の計画。前述の大きなフレームワークで、流量制限、負荷テスト、キャパシティ拡張、プレプランなどの対策が解決策に含まれていることがわかっている。では、これらの解決策はどのように効果を発揮するのか。また、それらの間に一定の順序はあるのか。解決策は例外タイプと強く関連している。異なるタイプには異なる解決策があるため、解決策も業務機能異常に対するものとインフラ異常に対するものに分けられる。業務例外に対する解決策。安定性保証は業務例外に対して「万一起きたらどうするか」という観点から主に解決策を考える。したがって、緊急時に備えて事前に準備しておく必要がある。業務例外の解決策は一般的に止血策、暫定解決策、長期解決策の3つに大別される。所要時間は段階的に増加し、問題解決の度合いも段階的に増していく。いずれも問題に対する解決策だ。止血策は通常コード変更やリリースを必要とせず、プレプランや設定、スイッチなどを通じて実施され、事前に計画と準備を行う必要がある。暫定解決策と長期解決策は通常コード変更とリリースを必要とし、時間がかかる。したがって、問題発生時は最も効率的な止血策を優先して実施する。止血策でも大きな損失が続く場合は、迅速に暫定解決策を考案して問題を解決する必要がある。暫定解決策はある程度問題を解決するが、軽微な機能上の問題、パフォーマンスの問題、設計上の不完全さが残る可能性がある。そのため、問題が緩和された後に安定的でエレガントな長期解決策を検討する必要がある。ただし、それは別のタイミングでの作業であり、安定性保証の作業範囲には属さない。業務機能の異常に対しては、日常の開発段階から事前に計画し、多次元・多段階でサービスデグラデーションが可能なスイッチや設定を準備し、異常発生時の緊急止血用にとっておく必要がある。それが計画だ。計画は演習を通じて検証し、計画の設定と実行の正確性を確保する必要がある。