アーキテクトの日記 - ソフトウェアの高可用性の実践

著者：JD Retail Liu Huiqing

I.はじめに

ソフトウェアの高可用性は一般的なトピックです。「高可用性」(高可用性) は通常、サービスの高可用性を維持しながらダウンタ​​イムを短縮するように特別に設計されたシステムを表します。計算式は、稼働率＝（合計時間－使用不可時間）÷合計時間です。

この記事では、エントリ ポイントとしての実装プラクティスの観点に焦点を当て、コラボレーション効率、テクノロジの実装、および運用仕様の観点から、高可用性の実装手順と実装の詳細をすべての人に示します。理解を容易にするために、最初に言語と語彙を統一し、次の図に示すように、ソフトウェア配信プロセスのさまざまな段階を見てみましょう。



 

ソフトウェアの高可用性が多くの課題に直面していると言われるのはなぜですか?

◦ デマンドデリバリーリンクの観点から、目的のデリバリーを完了するには、製品、研究開発、テスト、運用保守、および運用など、複数の利害関係者の緊密な協力が必要です。プロジェクトの要件によっては、何百人もの共同作業者がいる場合もあります.それぞれの責任は異なりますが、彼らは互いに協力し合い、お互いに依存しています.リンクに間違いがあると、稼働率に影響する可能性があります.

◦ 時間の観点から、年間稼働率 99.99% を達成したい場合、1 年間の障害許容時間は 365*24*60*(100%-99.99%)=52 分、ファイブ ナインの可用性率を達成するために許容される障害時間はわずか 5 分です。これは、問題が見つかってからアプリケーションを再起動するのにかかる時間とほぼ同じです。

◦ イテレーション効率の観点から、イテレーションとオンラインがなければ、問題が発生する確率ははるかに低くなります。ソフトウェアの反復効率と可用性の間には負の相関関係があり、両者の関係のバランスを取ることも大きな課題に直面します。

要約すると、私たちが直面している具体的な問題は次のとおりです。

◦ デマンド配信に伴う多くの協力者と長いリンクの問題をどのように解決しますか?

◦ ダウンタイム許容度が低いという問題にどう対処するか？

◦ 需要が頻繁に繰り返される現在の状況で、稼働率が大きく影響を受けないようにするにはどうすればよいですか?

2. コラボレーション効率の保証

認知的誤解

デマンド配信リンク全体から、リンクが段階的に増加するにつれて、情報伝達リンクの分岐が多くなり、伝達レベルが深くなることがわかります。これにより、次の 2 つの問題が発生します。

1. 情報伝達の効率が低下します。

2. 情報の精度が悪くなります。

これら 2 つの問題の最終的な結果は、コラボレーションの効率の低下です。





 

実務経験のない学生は、人数を増やせばデマンドデリバリーの効率が上がると考えがちです。実際には、この考えは完全に正しいわけではありません. 具体的な関係については、次の図を参照してください。





 

建物を建てるのと同じで、一人が一歩ずつ建てていくと、完成までに100日かかります。100人に手伝ってもらったら、家は1日で建てられますか? 答えは否定的です。

チームの理解 (デザイナー、煉瓦工、石工、配管工)、仕事のマッチング、リスク管理などのコラボレーション コストがあります。

プロセスの依存関係があります。たとえば、構造は設計に依存し、ソフトな装飾は常にハードな装飾の後に続きます。

組織全体 (請負業者、エージェント、請負業者) の人材の勾配と規模。

上記のすべては、単に人材を配置するだけで解決されるわけではありません。

プロセス仕様

連携効率向上の根底にあるのは、配信リンクのレベルを下げ、情報伝達リンクを短くすることで、情報の正確性と伝達効率を確保することです。（組織構築レベルの内容はここでは展開しません）

これには、今日の仕事を行い、今日の仕事を完了する能力が必要です。これを組織レベルではプロセス仕様と呼び、個人レベルでは仕事のやり方や責任感と呼んでいます。

現在の問題を次のリンクに先延ばしにしないようにしてください。そうしないと、後続のリンクのスケジューリングと配信効率に影響し、極端な場合にはやり直しが発生する可能性もあります。要するに、はっきりと考えて、穴を埋めないでください。製品要件は研究開発用、研究開発設計はテスト用、テストケースは製品などの配信ノードごとにあり、成果物は信頼できるものでなければなりません。

3つのテクノロジー着陸保証

デマンド レスポンス サイクルでは、アーキテクチャの設計、コーディングの実装、安全な起動、展開と運用、およびその他の生産段階の高品質な実装が、高可用性ソフトウェアの実装の前提と基礎となります。

建築デザイン

アーキテクチャ設計は、システムの初期実装コスト (ROI) とその後の運用と保守の難しさに影響を与えることが多く、マクロ設計スキームと実装の詳細におけるパラダイム制約の両方を含む、ソフトウェアのトップレベルの設計に属します。 .

• プロセス保証

アーキテクトに参加を呼びかける: コア トランザクション ノードと主要な需要の変化に参加するようアーキテクトを招待します。これは、穴を塞ぐための最も直接的かつ効果的な方法です。

設計文書の重視: スキームの明確な説明と関連する利害関係者の承認は、正しい道を歩むための前提条件です。

• 設計保証

災害復旧設計: 出口を確保し、事前に明確に考え、災害復旧設計を適切に行う必要があります。ロールバック、融合、再試行、およびダウングレードが可能です。

ロバスト設計: ステートレス設計、アンチヘビー設計、べき等設計、データ一貫性設計

エンコーディングの実装

建築設計が骨格なら、コーディングの実装は神経、血管、筋肉です。前者はどれだけ安定してどれだけ長く歩けるかを決定し、後者はどれだけ速く、どれだけ遠くまで行けるかを決定します。コーディングレベルで実装され、コードの老朽化と破損の程度です。

• プロセス仕様

コード レビューの仕組み: コード レビューは、システムの問題を見つけるだけの単純なものではありません。それは長期的な行動であり、組織文化の実装と継承のためのフォームとキャリアです. レビュー プロセス中に、ビジネス責任、設計とコーディングのコンセンサス、優れた標準指向の研究開発コンセンサスの境界が明確になりました。チームの戦闘力を確保するための土台となる、具体的な事例を通じて具体的な指導を行うことに相当します。

研究開発プロセスにおける多くの問題は、コード レビュー メカニズムを通じて発見および解決できます。たとえば、次のようなものがあります。

◦ 一時的な要件の設計と実現にどのように対処するか?

◦Nの「Hello World!」の書き方についてどう思いますか?

◦ 設計パターンとオーバーエンジニアリングの境界を理解する方法は?

◦ 現在の段階の成果物をどのように評価しますか?

◦ 単体テストの導入は必要か？

• コーディング標準

◦ エラーハンドリングはありますか？呼び出された外部サービスに対して、戻り値のチェックや例外処理は行われていますか?

◦ 設計は、既知の設計パターンまたはプロジェクトで一般的に使用されるパターンに従っていますか?

◦ 開発者が書いた新しいコードは、既存のSDK/フレームワークの機能で実装できますか? このプロジェクトには、すべてを再実装せずに呼び出すことができる同様の関数がありますか?

◦ 役に立たない、重複した機能、または異なるバージョンの jar パッケージの依存関係がプロジェクトに導入されていませんか? (json ライブラリ、各種ユーティリティ)

◦ 削除できる無駄なコードはありますか?

◦ コードはどの程度読みやすいですか? コメントは十分ですか？

◦ パラメータの受け渡しに誤りがないか、不変と思われる条件が本当に満たされていることを確認するためのアサーション (Assert) または判断はありますか?

◦ 境界条件はどのように処理されますか? switch ステートメントのデフォルト ブランチはどのように処理されますか? ループが無限ループになる可能性はありますか?

◦ リソースはどこに適用され、リリースされますか? リソース リークの可能性はありますか (タイムアウト、メモリ、ファイル、オブジェクト参照、大きなオブジェクト、スレッド数などを含む)? 最適化の余地はありますか？

◦ コードはどの程度効果的ですか? 最悪のシナリオとは？

◦ コード内、特にループ内で最適化できる明らかな部分はありますか (文字列操作は StringBuilder で最適化できますか)?

◦ システムとネットワークへの呼び出しはタイムアウトになりますか? それに対処する方法は？

◦ コードは簡単にテストできますか (メソッド行の数、循環的複雑度、および入力パラメーターと出力パラメーターの定義が適切かどうか)?

変更は、古いバージョン、履歴データ、およびアップストリームの互換性に影響しますか?

インターフェースの設計では、冪等性、同時実行性、オーバーリーチ、劣化などの問題が考慮されていますか?

複数のデータ ソースからのキャッシング、データベース パフォーマンスの問題、およびデータの一貫性の問題はありますか?

◦ オンライン プランでは、グレースケール プランと不整合なデータ ステータスが考慮されていますか?

安全なオンライン

オンライン障害の 70% は何らかの変化によって引き起こされており、そのかなりの割合がオンラインのイレギュラーによって引き起こされています。したがって、安全にオンラインに接続することは非常に重要です。

• プロセス仕様

◦ 頻繁にインターネットに接続することは固く禁じられています。たとえば、週に 2 回までです。

◦ ピーク時にオンラインになることは固く禁じられています。問題の範囲を縮小します。

◦ 許可なくオンラインにアクセスすることは固く禁じられています。変更がある場合は、テスト検証と製品返品確認に合格する必要があります。

• プロセス仕様

◦ トラフィックのピックアップ: マシン jsf オフライン/np の最初のバッチを選択してトラフィックをピックアップします (コールド スタンバイとして選択)。

◦ ログを確認します。ログを観察して、削除されたマシンにトラフィックがないことを確認します。

◦ サービスの 予熱: マシンが正常に起動し、コア ビジネス インターフェイスを予熱する必要があることを確認します。

◦ ハング トラフィック: オンライン マシン トラフィックをマウントします。

◦ インジケータを確認します。オンライン マシンの mdc インジケータ（CPU、メモリ、負荷）が異常かどうか、およびログが異常かどうかを観察します。

展開操作

高可用性を実現するための非常に重要な手段は、容量の冗長性です。方向性とアイデア、および特定の状況に応じて拡張できる具体的な実装の詳細と戦略を以下に示します。

• ネットワーク

◦ 事業者レベルでは、China Unicom、China Telecom、China Mobile など。

◦ リンク ノード、VIP、CDN、ルーター/スイッチ、リバース プロキシ、クライアント、ブラウザなど。

• ストレージ

◦ データベースのマスター/スレーブ アーキテクチャであろうと、ES のコピー アーキテクチャであろうと、ストレージの高可用性を実現する手段であり、重要なデータは関連する機能を十分に活用する必要があります。

◦ データ構造を設計するときは、シャント戦略、キャパシティ プランニング、データ分割、または異質性についても適切に行う必要があります。例: ホット キーのキャッシュ、データベース テーブルのスループットのボトルネック、データベース接続数の制限、および高可用性に影響するその他の問題を回避します。

• サービス

◦ 水平 拡張: リソースを追加して容量を拡張できるようにすることは、サービスにとって非常に重要です。

◦ サービスの グループ化: ビジネス パーティーまたは使用シナリオに従って、サービスはさまざまな粒度で分離され、極端な状況が相互に影響を与えるのを防ぎます。

◦極限 戦略：極端な異常事態における防御戦略であり、事故発生後のサービスの信頼性を可能な限り維持することを目的としています。例: 電流制限、ヒューズ、再試行、高速障害など。

◦ グレー スケール戦略: 新しい機能が開始されると、問題が発生する可能性が最も高くなります. 成熟したトラフィックのグレースケール機能を持​​つことが、問題の範囲を制御するための鍵となります.

4つの動作基準保証

動作仕様

1. 監視できます：システムの稼働状況

2. 警察を呼ぶことができます：異常な状況は、システムの関係者に通知することができます

3. 発見可能：問題発生後、問題の原因を迅速に特定できます。

4. 修理可能：異常な状況が発生した場合、問題は最初に修理できます。

緊急計画

高可用性とは、ダウンタイムに対する許容度が低く、トラブルシューティングと修復の時間がなく、脆弱性のトラブルシューティングのためにコードを開く時間がないことを意味します。これには、予見可能な障害の問題のほとんどを解決できる緊急計画の完全なセットが必要です。

• プロセス仕様

◦ 最初に生産を再開します。

◦ 2 回目の トラブルシューティング。

詳細な事故緊急対応マニュアルについては、次の図を参照してください。





 

• プロセス仕様

◦ ネットワーク、サービス、ストレージの 3 つの次元で対応する計画を策定し、緊急計画リスト (ファイル名: チェックリスト) を独自のコード ベースに記入して、内容を継承および更新し続けます。

◦ 予測可能性 、つまり、問題を引き起こすシナリオを明確に記述する必要があります。例: 現在の進捗状況 (10,000/日) によると、データベース データの増加に伴い、10 か月後にデータベース テーブル (xxx テーブル名) にスロー クエリが表示されると推定されます。

◦達成可能性 、問題の解決策を排除する能力。例: 履歴データのアーカイブ タスク (xxxWorker) を開始し、履歴データをアーカイブ データベースに転送します。

規格準拠

プロセスや規範がいかに優れていても、それらを実装するための対応するメカニズムがなければ、それは鏡の中の花、水の中の月のように美しく見えますが、実際には役に立ちません。実行可能で測定可能であることは、目標に従って改善するための前提条件です。そこで、仕様の実装を支援する「高可用性とコンプライアンスの定期的な自己検査表」というツールを紹介します。

5つのまとめ

この記事では、「高可用性に大きな課題があるのはなぜですか?」という質問について説明し、デマンド デリバリのプロセスにおけるコラボレーション効率の重要性を強調し、「今日の仕事、今日の仕事」という動作原理に従う必要がある理由を指摘します。 "。アーキテクチャの設計、コーディングの実装、安全な起動、展開と運用などの側面から、技術の実装保証に関連するガイドラインと実装の詳細を詳細に紹介します。最後に、打ち上げ後の運用の観点から、緊急計画、定期セルフチェック表などの実用的な運用保証ツールを提供します。読者の助けになれば幸いです。

{{o.name}}

{{m.name}}