可用性と信頼性 — クラウドのためどのように変えるか
English version is here
TL; DR
クラウドに移行する際に、クラウドプラットフォームを最大限に活用し、Google検索、Gmail、またその他の多くのインターネットサービスが実際に達成するような継続的な可用性を実現するためには、可用性と信頼性に関する考え方に適応する必要があります。
前書き
この投稿は、次のトピックを取り上げるシリーズの最初の投稿です。
- 背景と目標（この投稿）
- 主要な概念（設計パターン、SREなど）
- 高可用性のためのGCPサービス
バックグラウンド
可用性とクラウドに対する私の関心は、NetflixのクラウドアーキテクトをリードするAdrian CockroftによるGOTO 2012での講演の動画に出会ったときに始まりました。現代のクラウドプラットフォームとNetflixがそれ以来多くの進歩を遂げているにもかかわらず、今日でもこれは興味深いと思います。キーポイントは次のとおりです。
● データセンタービジネスから抜け出し、ビジネスの差別化に焦点を当てる
● マイクロサービスアーキテクチャ
● Chaos monkeys!
● CICD
● オープンソースへの貢献
非常に高い可用性が最優先事項であり、システムが対処できることを証明するために、サービスとゾーンを停止します。
可用性/信頼性とユーザーエクスペリエンス
この記事の基礎となるいくつかの基本原則があります。
● ミッションクリティカルなビジネスシステムは、基盤となるインフラストラクチャ、プラットフォーム、フレームワーク、および依存するコンポーネントにおける障害を前提として構築され、さまざまな障害時においても動作することを確認する必要があります。
● 信頼性と可用性はユーザーの観点から検討する必要があり、重大な問題が発生した場合でもユーザーが影響を受けないようにする必要があります。
このシリーズが完了するまでに、GCPでこれらの原則を実践的に採用する方法について、非常に明確なアイデアが得られることを願っています。
従来のHAおよびBCP / DR
従来のオンプレミスの高可用性アーキテクチャ、ビジネス継続性計画、およびディザスタリカバリ、次のように特徴付けられます。
● メイン+フェイルオーバーの2つのデータセンターを設置
● オーバープロビジョニングと のインフラストラクチャ
● データベースレプリケーション
● RPO（目標復旧地点）=許容されるデータの損失
● RTO（目標復旧時間）=フェイルオーバーまでの許容時間、サービスの復元
● 更新およびメンテナンスのための定期的なダウンタイム
その結果、可用性が低下し、コストが高くなります。
クラウドネイティブの可用性
これとは対照的に、クラウドネイティブ可用性のアイデアがあります。
ライブアップデート：アップグレード、更新のためのダウンタイムなし （GoogleとGCPの主要な差別化要因）
使用した分を支払い、支払った分を使用する：アクティブな冗長性が組み込まれています、
ユーザーエクスペリエンスの適切なコントロール：最悪の場合
目標は100％の可用性ですか？
高可用性にはコストがかかります。イノベーションとビジネスの進歩が損なわれる可能性があります。時間とお金の大きな継続的な投資が必要です。
ただし、ダウンタイムと不安定性にもコストがかかります。システム運用に忙しすぎると、イノベーションとビジネスの進歩が損なわれる可能性があります。また、ユーザーと顧客からの評判が損なわれ、全体的に、チームにストレスを与えます。
それでは、答えが「そうでもない」の場合、目標は何ですか？
Cloud Nativeとの最良のトレードオフ
目標は、速度と信頼性の間で最適なトレードオフを行うことです。
定められたコストで可用性と速度のトレードオフを最適化する
コストは一定と見なされることに注意してください。ビジネスに必要な速度と信頼性を実現するために必要なものを投資してください。
私が開発する理論は、最良のバランスは、クラウドネイティブデザインと「Googleのベスト」を採用することで、達成されるというものです。
パート１まとめ
これで、パート1「背景と目標」は以上です。パート2「重要な概念」では、設計パターンをさらに深く掘り下げ、サイト信頼性エンジニアリングとゼロダウンタイム展開に触れます。
