『Google Cloud で信頼性を高めるためのアプローチ』のセッション動画を視聴したらものすごく参考になりました。#GoogleCloudNext

視聴したセッション

今回視聴したのは昨年開催された『Next OnAir Japan』の中のインフラストラクチャシリーズの『Google Cloud で信頼性を高めるためのアプローチ』というセッションです。

Google で生まれたSite Reliability Engineering（SRE）の考え方をベースにGoogle Cloud 上で信頼性を高めるためのアプローチ方法や構成していくうえでのポイントを解せるしてくれているセッションになります。

SREについてはこちらをに参考資料を載せておきます。

イベントの予習になったらなと軽い気持ちで見始めたセッションでしたが、Google Cloudだけでなくクラウド上でアプリケーションやWeb サービスを構築する上で非常にためになる考え方について解説されていたので、簡単にまとめてみました。

動画はこちらから視聴が可能です。

構成

セッションは以下の三つの話題を主軸に構成されていました。

1. 信頼性に関する要件整理のアプローチ
2. SLOを達成できるクラウドプロバイダとアーキテクチャの選択の指針
3. 信頼性の高いアプリケーション構築の指針

信頼性に関する要件整理のアプローチ

信頼性の高いアプリケーションを作るうえで、信頼性に関するビジネス要件を定義していくことが、非常に重要になってきます。このステップには時間をかけて十分に整理していくことが重要です。

ビジネス要件を考える際に

• 可用性の高さ
• 常時稼働
• ダウンタイムなし

というような、高い信頼性条件を前提に考えていくケースも多いと思います。

しかし重要なのはユーザーの満足度とコストの面でバランスが取れているかという点です。

一般的に可用性が１００％に近い完全なサービスであっても、ユーザーの満足度は鈍化していく傾向にあります。これはいくらサービス側の可用性が高くても、ユーザーはネット環境やデバイスの問題でサービス停止を経験することになるためです。

つまり、高い可用性＝信頼性と考えるのではなく、ユーザーの満足度とコストの二つを軸として最もバランスの取れているスイートスポットを見つけることが、信頼性の要件を定義する上で重要になってくるということです。

このようなユーザージャーニー（利用客目線）に沿った要件が必要になります。また、実際に構築を行った後、どのように顧客の満足度を計るのか、という点も重要になってきます。

ここで出てくるのがサービスレベル指標（SLI）とサービスレベル目標（SLO)です。

SLIは『定義した信頼性への評価をどのように図るか、その方法』のことです。例えば稼働率やレスポンスタイムなどがこれに当てはまります。

SLOは『数字としてどの程度を目標にするのか』というより具体的なものになっています。

この二つが満たされているかどうかでユーザーが満足しているか否かを計るわけです。こちらのセッションではリテールバンキングの例を出して解説をしていました。

SLOを達成できるクラウドプロバイダとアーキテクチャの選択の指針

ここでは先に説明したSLOを達成していくためにどんなプロバイダを選択していくのかということについて解説がなされていました。

プロバイダはSLOの一部を消費するものにもなるのでここでいしっかりと選定していく必要があります。プロバイダを選ぶうえでの指標となるのが、

• オンプレミスのアップタイムを超えられるのか
• アプリケーションのスタックの信頼性向上が可能か
• 信頼性の目標達成が容易になるか

といった基準になります。また、複数リージョンや複数ゾーンを使用する場合には、複数の場所に簡単にワークロードを迅速かつ容易にデプロイできる機能を利用できるかといったようなことも選定基準に入ってきます。

これらを含めたクラウドサービスを選定する上でのポイント４つというもの基準として適切なクラウドサービスを選んでいくことも、結果として信頼性の向上につながっていくというわけです。

信頼性の高いアプリケーション構築の指針

次に信頼性の高いアプリケーションの構築をしていくうえで重要な考え方についてです。

アプリケーションの稼働率ばかりに目が行きがちです。しかしアプリケーションが大規模であればあるほど、障害が起きる頻度よりも、どこで障害が起きたのか？その障害が起きたことによる影響はどの程度の範囲に及んでいるか？という点が重要になってきます。

障害を最小限に抑えることはもちろん、いかに早く復旧を行えるかも大切です。障害が発生しても常に最高のユーザーエクスペリエンスを提供していくことが信頼性の高いアプリケーション構築で重要な考え方になって行きます。

この考え方をアーキテクチャ&デザインとデプロイメントの観点から見たものがこの項目で解説されていました。

アーキテクチャ＆デザイン

クラウドのコンポーネントを活用した構成をとることで個々にスケールすることが可能になります。

• 信頼性要件に応じてマルチゾーン構成などを採用する。
• コンテナではAnthosを、VMではマネージドインスタンスグループなどのオーケストレーション機能の活用。柔軟のある構成をとる
• ロードバランシングを使用した並列デプロイメントと段階的なトラフィックの意向が可能な構成にする。

コンポーネントを最大限活用することで、問題発生時の切り戻しが容易になる、影響が一部に抑えられる等のメリットがあるので積極的に活用をしていくことが重要です。

デプロイメント

デプロイメントをモダナイズし、リスクを下げていきます。

アプリケーション障害は多くの場合、アプリケーションのデプロイ時やデータの更新時に起こります。こういった場合には変更管理に問題があるという原因が考えられます。

• 異なるゾーンやリージョンで実行されているアプリケーションのデプロイメントを自動化する。
• ロールアウト時のSLIを監視し、問題を検知可能にする。
• ロールバック処理も自動化、問題発生時に即座に切り戻し可能にする。

このようにできるだけデプロイメントに関しての項目を自動化することで、アプリケーションの信頼性が高まります。

まとめ

今回のセッションでは信頼性を高めることの重要性や、その考え方について詳しく解説がされていて非常にためになりました。来週行われる『Google Cloud Next ’21 Recap: Japan』でも新情報が続々出てくると思うので、インフラストラクチャのシリーズも注目してみることにします。

まだこのイベントの参加申し込みは可能なので興味があるのに申し込みがまだって方はぜひ申し込んでみてください。

前回のブログでは『Google Cloud Next ’21 Recap: Japan』の申し込み方法とどんなセッションが予定されているかを簡単にまとめているのでぜひそちらもご覧ください。