Googleのクラウド導入フレームワークを翻訳して紹介

記事タイトルとURLをコピーする

G-gen の杉村です。 Google は The Google Cloud Adoption Framework というフレームワーク (考え方や施策の枠組み) を公表しています。
このフレームワークでは、組織がクラウドを導入するときにどのように考え、施策に取り組むべきかについての指針を示しています。
技術的な視点にとどまらず、 組織づくりや経営層の関わり方も含めた、包括的なフレームワーク となっています。

以下のページから無料でホワイトペーパーを閲覧することができます。

cloud.google.com

ただし、ドキュメントは残念ながら英語でしか公開されていません。
当記事では The Google Cloud Adoption Framework を抄訳 (逐語訳ではなく要約しつつ翻訳) し、紹介したいと思います。

当記事の内容は、図を含め、前述の The Google Cloud Adoption Framework ホワイトペーパーから抜粋・翻訳したものとなりますが、一部に翻訳者 (杉村) の解釈や解説を含むことをご了承ください。
また (※) で挿入された注釈は翻訳者によるものです。

第一部: エグゼクティブ・サマリー

1-1. 四つのテーマ、三つのフェイズ

The Google Cloud Adoption Framework には4つのテーマと、3つのフェイズがあります。

4つのテーマは以下です。

The Google Cloud Adoption Framework より引用した図を翻訳したもの

  • Learn (学習)
  • Lead (リード)
  • Scale (スケール)
  • Secure (セキュア)

Learn (学習) は、技術部門のメンバーをスキルアップさせたり、あるいは技術のあるパートナー企業との連携を行うことを扱うテーマです。

Lead (リード) は、クラウド移行にあたり経営層やリーダー層の支援を得られているか、それにより部署間連携が取れているか、モチベーションは十分か、どのようなチーム編成となっているか、といった内容を扱うテーマです。

Scale (スケール ※) は、適切なクラウドサービスの利用や自動化を駆使することで、インフラに関わる運用負荷を減らしたり、アプリケーションのアップデートの負荷を減らしたりするためのテーマです。
※スケール = コンピューティングリソースやストレージを、使用状況に応じて拡張したり縮小したりすることをスケーリングと言い、動詞的に「スケールする」のように用いる

Secure (セキュア) は、セキュリティに関するテーマです。多層セキュリティ、IDベースのセキュリティを基本とします。

これら4つのテーマごとに、それぞれ3つのフェイズ (進捗度) があります。

The Google Cloud Adoption Framework より引用した図を翻訳したもの

  • Tactical (「戦術」段階)
  • Strategic (「戦略」段階)
  • Transformational (「柔軟」段階)

Tactical (「戦術」段階) は、個別の取り組みが存在しているものの、組織として一貫した状態にはない、という状態です。この状態での関心は、個々のシステムのコスト削減や、波風の少ない移行などに留まっており、将来の拡張などにはまだ関心がありません。ここが短期的なゴールになります。

Strategic (「戦略」段階) は、将来に渡る観点が存在し、個々の取り組みが管理されている状態です。また必要な関係者の巻き込みはできており IT チームは成果を出し始めています。ここが中期的なゴールとして捉えられます。

Transformational (「柔軟」段階) は、クラウド運用がスムーズに実現しており、関心はクラウド上にあるデータやそこから得られる洞察にある、という状態です。 IT 部門、もしくは相当するチームがイノベーションのエンジンになっており、これが長期的なゴールといえます。

1-2. クラウド成熟度

前述の4テーマ、3フェイズのうち、組織が現段階でどこにいるかを確かめる際は、 クラウド成熟度 をチェックします。
以下の図のように、組織は各テーマごとに、上から下へ成熟していきます。

The Cloud Maturity Scale - The Google Cloud Adoption Framework より引用した図を翻訳したもの

1-3. エピック

クラウド成熟度スケールを使って自組織の現在地が分かったら、次は前へ進むための方法を考えます。
クラウド導入のためのそれぞれの取組みのことを、ここでは エピック (※叙事詩のこと) と呼びます。
各エピックはお互いに重複しないよう定義されています。また、各個人のストーリーにブレイクダウンできます。

下の図は、エピックを People (人) 、Technology (技術) 、 Process (プロセス) に分類したものです。
色がついた部分は、各テーマに対応しています。Learn (学習) = 緑、 Lead (リード) = 黄、 Scale (スケール) = 青、 Secure (セキュア) = 赤です。
全てのエピックを実施できない場合は 色付きの部分にまず取り組む ことが、成功への近道です。

Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの

1-4. The Google Cloud Adoption Framework とは

先に紹介した「クラウド成熟度測定」で自組織の現在位置を確認したあと、エピックを使ってゴールへの施策を決めます。
なお The Google Cloud Adoption Framework は Google Cloud (旧称 GCP) だけでなく どのクラウドに対しても適用できる 方法論です。

Google Cloud の Technical Account Manager (TAM) の支援を仰ぐことで、超上流のアセスメントを行うことができます。
これによりクラウド成熟度を測定したり、それに伴うトレーニングの優先度決定や、チェンジ・マネジメント (※) の仕組みの策定、パートナーとの関わり方、クラウド運用体制、アカウント管理手法などを検討できます。

※ チェンジ・マネジメント = 経営学用語。経営戦略や組織の変革がスムーズに行われるようにマネジメントすること、またその手法

TAM は、クラウド化の最初のプロジェクトから、その組織がクラウドファーストな組織になるまで、伴走することができます。

The Google Cloud Adoption Framework より引用した図を翻訳したもの

1-5. はじめかた

1-5-1. クラウド成熟度の測定

ステイクホルダー (関係者) に4つのテーマ、すなわち Learn (学習) 、 Lead (リード) 、 Scale (スケール) 、 Secure (セキュア) を説明し、アセスしてもらいます。
後述のテクニカル・ディープダイブで、各テーマごとのサマリー表が示されるので、それを元に議論を勧めます。

1-5-2. ゴールを決める

クラウド成熟度のうち、どの段階をゴールとするかを決めます。
この段階で、 IT 組織の中でも意見が合わないことが多いでしょう。
その人が組織の中のどの階層にいるかによって、クラウド化によって得られる利益 vs リスクに対する考え方が異なるからです。

まずは足がかりとして、短期戦術的な目標にフォーカスして議論することも検討しましょう。

1-5-3. クラウド導入プログラムを計画する

ゴールとのギャップがあるエピックについて、施策を実施します。
いずれの施策も、最終的に以下の4つのいずれかに行き着くようにしてください。

  • トレーニングプログラムの策定
  • チェンジ・マネジメントプログラムの策定
  • クラウド運用モデルの設計
  • クラウドアカウントのセットアップ

Getting Started - The Google Cloud Adoption Framework より引用した図を翻訳したもの

1-5-4. ちょうどよいワークロードを見つける

※ワークロード = 元は仕事量、処理量という意味。ここではシステムが処理する業務やその性質、あるいはシステム自体を指す

初めにクラウド化するのは「 シンプルでビジネスクリティカルではないシステム 」が最適です。
こういったシステムを最初にクラウド化することで、組織のクラウド能力を鍛え、自信をつけることに繋がります。
能力が高まってくれば、将来はより複雑でクリティカルなシステムのクラウド化にも対応できます。

最初のプロジェクトはワークロード主体で考えるべきか、あるいは運用方法主体で考えるべきか、悩むこともあるでしょう。
スタートアップ企業では、迅速に商用環境へデプロイすることを優先し、運用負荷は甘んじて受けることもあるでしょう。
トップダウンでクラウド導入を進める大企業であれば、クラウドを本番導入する前にまずは運用体制をしっかり確立することもあると思われます。

これらの検討に正解は無く、組織ごとに異なるものです。

第二部: テクニカル・ディープダイブ

※ディープダイブ = 技術要素などに対して、深堀りして紹介したり考察すること。 IT 界隈でしばしば使われる言葉

2-1. クラウド成熟度の各段階について

2-1-1. Tactical (戦術) 段階

Tactical (戦術) 段階は、既存 IT の コスト最適化 という短期的な目標ともいえます。
クラウド化によってあまり使われていないコンピュートリソース (※主に CPU ) やストレージを最適化したり、運用負荷を下げたり、調達やセットアップの工数を下げたりすることが該当します。

この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) に大きな変更は起こさないことが多いでしょう。
とはいえ、これもクラウド導入において重要なフェイズです。

Tactical (戦術) 段階では、期待する成果は TCO (※) 分析への影響度合いで判断します。
分析の結果として得られる利益が少ない場合、すぐに Strategic (戦略) 段階へ行きたいと考えるかも知れませんが、商用環境でクラウドを使った経験がない場合は十分に気をつけてください。この段階で得られる経験がチームに成功体験として残れば、その経験自体がのちのフェイズのための重要な基礎となるでしょう。

※ TCO = Total Cost of Ownership, 総所有コスト。資産を調達してから廃棄するまでに発生する、金銭的・人的等のコストの総額

2-1-2. Strategic (戦略) 段階

Strategic (戦略) 段階は IT組織がもたらす価値の増大 という中期的な目標です。
この段階を達成するには、 IT チームの開発・運用に関する効果や効率が飛躍的に向上しなければなりません。
それには、アーキテクチャのモダナイゼーション (近代化) によりクラウドネイティブ (※) なサービスを活用することも含まれます。

※クラウドネイティブ = 「クラウドありき」だったり、クラウドのメリットを存分に活用している状態を指す。サービスやシステムに対して使うこともあれば、組織や個人に対して使う言葉でもある

この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) な変化が、一定の範囲で必要です。
変化は IT 組織の一部に留まるかもしれませんが、組織の将来像 (青写真) を示したり、成功体験として残るという意味で、最終段階である Transformational (柔軟) 段階への布石として重要です。

2-1-3. Transformational (柔軟) 段階

Transformational (柔軟) 段階は、 ITがイノベーションのエンジンである状態 を目指すという長期的な目標に当たります。
この段階では IT がビジネス変革を推し進める原動力となっており、もはやコストセンターではなくビジネスに不可欠な存在です。

以下のような要素がキーとなります。

  • 既存データから洞察を得ること
  • 新しいデータを収集・分析すること (感情、画像、音声など)
  • 機械学習で Predictive Analytics (予測的分析 ※) や Prescriptive Analytics (処方的分析 ※) を行うこと

※ Predictive Analytics = 予測的分析。機械学習により、将来起こり得る事象や数値を予測すること
※ Prescriptive Analytics = 処方的分析。機械学習により、意思決定の自動化、もしくはサポートを行うこと

また IT 組織自体もスピード感を持ってイノベーションを提供できるよう、上記のようなデータドリブンな (データ起因の) アプローチを取る必要があります。

組織として、 SLO の合意・計測を適切に行い、知見の横展開や、個人やチームが主体的に意思決定できることを促進するようにします。
またクラウドサービスやクラウド流のベストプラクティスが、組織の新しい常識になる必要があります。
組織は、失敗や障害を含めて実験的な取り組みを正しく評価し、成果とコストを適切に算定することで、この新しい常識を下支えできるでしょう。

2-2. 各テーマごとのクラウド成熟度

関連エピック: スキル向上外部の知見

2-2-1. Learn (学習)

Tactical (戦術段階)

  • 自己動機づけに頼った、個人単位でのスキル向上
  • オンラインドキュメントや YouTube
  • パートナーが全体的な知見をカバー
  • パートナーがクラウド環境への admin 権限を持つ

スキル向上は個人のベストエフォートに任されており、オンラインドキュメントや YouTube といった無料の教材を使っています。
この段階ではサードパーティのパートナーが完全に頼られており、クラウド資産への特権アクセスが可能です。
技術的な質問や、有事の際のエスカレーションもパートナーが一手に引き受けている状態です。

この段階に至るために、クラウド要員を雇う必要はなく、既存のメンバーで到達できるでしょう。

Strategic (戦略段階)

  • トレーニング開催あり
  • 資格試験への支援あり
  • クラウド関連業務での人材募集あり
  • パートナーが緊急時のみ発動するクラウド環境への admin 権限を持つ (Break-glass admin access ※)

※ Break-glass 〜 = 緊急時に稼働するものを意味する。火災報知器のアラームを鳴らすためにガラスを割ることから

定期的なスキル向上プログラムが IT 要員に対して提供されている状態です。
資格試験取得が推奨され、予算も確保されています。

サードパーティのパートナーは、社内の IT 要員がまだ持っていないスキルや、内製で到達するには狭く深すぎる領域の知見をカバーします。
技術的な質問や有事の際のエスカレーションについては、一次受けは内部の IT メンバーが受けます。
そこで解決できない場合の第2層として、サードパーティのパートナーがエスカレーションを受けます。
そのため、パートナーは普段は制限付きのアクセス権限しか持っておらず、有事の際に必要な権限へ昇格する仕組みとなります。

この段階ではクラウド用の新しいポジションが用意され、採用施策が始まっています。

また各 IT メンバーにはテスト用のクラウド環境 (サンドボックス) が用意され、検証作業や新しいアイデアのテストを行うことができます。

Transformational (柔軟段階)

  • 個人同士が相互に学びあう文化あり
  • wiki, テックトーク(※), ハッカソン
  • IT 要員の役割や責任範囲が刷新されている
  • パートナーは補強的な役割のみであり、特権を持たない

※テックトーク = 技術に関する意見交換会、知見共有会など

この段階では、スキル向上は継続的で、相互的に行われます。
定期的なトレーニングに加えて、 IT チームや個々の従業員は、定期的にハッカソンやテックトークを開き、知見を共有します。
IT メンバーはブログ記事や講演を通じて、業界をリードする立ち振舞いをすることが推奨されます。
これは IT メンバーの成長の意味もありますが、新たな採用に繋がるという点で一石二鳥です。

クラウドファーストな IT 組織として、 IT 部門の役割と職責は、必要な再定義が完了している状態です。

サードパーティのパートナーは、補助的な役割のみを担います。
特権管理権限は持ちません。ほとんどのエスカレーションは内部で解決し、全てのインシデント対応手順が内部で完結します。

2-2-2. Lead (リード)

関連エピック: スポンサーシップチームワーク

Tactical (戦術段階)

  • ある特定プロジェクトの特定個人によりクラウド導入が行われる
  • IT 部門内の別部署との連携は難しい
  • 上長からの承認はあるものの、予算は限られている

この段階では、スポンサーシップ (上長・幹部からの支援) は単一部門の上級管理職からのものに限られている状態です。
といっても、この上長はクラウド導入を承認し、進捗が芳しくないときのエスカレーション先であるに過ぎません。

クラウド導入は個人的なクラウドへの興味を持っている一部のメンバーによってのみ、行われます。
他の IT メンバーとの連携は、既存組織の構造次第で制限されてしまいます。なぜなら、 IT 部門員の職責の範囲は、割り当てられたプロジェクトやビジネス部門の管轄内・予算内に限られてしまっているからです。
また彼らの成果は末端で利用される IT だけに現れており、組織の中央の IT に還元されることはありません。
結果として「かろうじて生存しているクラウド」や「クラウド・シャドーIT (※)」のようになってしまいます。

※シャドー IT : 中央の IT 部門によって承認されていない IT ツール等を事業部門やメンバーが勝手に使っていることを指す。一般的にセキュリティリスクである

Strategic (戦略段階)

  • プロジェクト横断で集まった少数のクラウド推進派グループによりクラウド導入が進む
  • このグループ外との連携は難しい
  • CxO レベルの幹部からの承認があり、予算もついている

この段階では C レベルの幹部 (※) からのスポンサーシップを受けられるようになっています。
レポートライン上の各マネージャは、クラウド導入にあたり目標や KPI を明確に定められています。
上長からの支援により、他の IT 部門やビジネス部門との水平連携が可能になっています。

※ Cレベル = CIO, CTO など C から始まる幹部職

いまだ従来型の SLO (Service Level Objectives, サービスレベル目標) が、検証のスピードやイノベーション、障害からの回復よりも優先されています。

この段階では、クラウド導入は少数精鋭の機能横断・プロジェクト横断のチーム (Center of Excellence, CoE) により進められています。
この CoE チームにはアプリケーションアーキテクト、ソフトウェアエンジニア、データエンジニア、ネットワークエンジニア、 ID / ディレクトリ管理者、運用担当者、セキュリティ担当者、財務担当者など、コアとなる役職が揃っている状態です。
チームのメンバーは、専務の場合も兼務の場合もありますが、役職名や評価軸は新しい役割に応じて刷新されています。
IT 組織などの関係者と技術業界知識に明るい、専任の技術マネージャーがいることが望ましいでしょう。

Transformational (柔軟段階)

  • 自主的なプロダクト開発チームが複数ある
  • エラーバジェット (※) と "批判なし" のポストモーテム (※) が CxO レベル幹部に認識されている
  • 組織全体で定期的に進捗が更新される

※エラーバジェット = 事前に定める障害に対する予算であり SLO に基づき算出される。これが残っているうちは新しいリリースが可能、などのように使われる
※ポストモーテム = 語源は「検死」。インシデントとその対応が完了した後に、事象・対応・原因・根本対策などをまとめる再発防止目的のドキュメント。障害報告書と似ているが報告ではなく改善が目的である点でニュアンスが異なる
※いずれの用語もオライリー社による出版の『SRE サイトリライアビリティエンジニアリング』に詳しい。同書は Google のメンバーにより執筆され SRE という用語を広く普及させた

スポンサーシップは、マーケティング、財務、オペレーション、人事などをも含む CxO レベル幹部全体から受けられるようになっており、その下位のマネージャ陣にも行き渡っている状態です。
そのおかげで、実験とイノベーションが大事であるという文化が全体に行き渡っています。
エラーバジェットの概念が CEO まで理解されており、批判を伴わないポストモーテムの文化が IT 組織に浸透しています。

チームは、透明性がありオープンな情報共有が可能な環境で働くことができており、各種決定権限を持っています。
アドホックな検証を行うために、承認を得たりリソースの準備を待つ必要はありません。
データガバナンスやコストコントロールは自動化されています。
障害すら、後進のための貴重な教訓として歓迎されます。個人による失敗は個人に帰すことはせず、組織としての欠陥と解釈され、叱責はありません。

2-2-3. Scale (スケール)

関連エピック: アーキテクチャCI/CD (※) 、 IaC (※)

※ CI/CD = Continuous Integration / Continuous Delivery 。継続的インテグレーション・継続的デリバリーと訳される。前者は自動化によりソフトウェアのビルド・テストのスピード・効率を向上させる手法。後者は自動化を駆使してサービスのリリースのスピード・効率を向上させる手法
※ IaC = Infrastructure as Code 。IT インフラをコードないし定義ファイルで定義して再現性確保・自動化・バージョン管理を可能にする手法

Tactical (戦術段階)

  • クラウドリソースは手動で展開される
  • アプリは長期運用の VM に展開。 OS の保守が必要
  • 環境変更のレビューは手作業
  • 環境変更のリスクは高く、頻度は低く、手作業

この段階では、マネージドサービス (※) やサーバレス (※) の利用は限定的です。
自ら運用する必要がある 仮想マシン (VM ※) に頼っています。
しかしこれは、管理対象が増えるに連れ、対象ごとに意図しない設定のズレが起きるなどの原因となり、管理運用の工数が増え続けます。
サーバの数が増えれば増えるほど、管理・運用の対象は増え、監視対象も増え、パフォーマンス情報の収集対象も増えていきます。

※マネージドサービス = クラウドサービス側でインフラが管理されるサービス。物理層や OS 層を意識せずソフトウェアレベルで利用することができる。例として Google Cloud (GCP) の Cloud SQL や Amazon Web Services (AWS) の Amazon RDS はリレーショナルデータベースのマネージドサービスである
※サーバレス = マネージドサービスのうち、サーバの概念がない (ユーザから見て隠蔽されている) サービスのこと。利用前にインスタンスの展開等が必要なく、即座に利用できる。 Google Cloud (GCP) の BigQuery や Amazon Web Services (AWS) の AWS Lambda などが該当
※仮想マシン (VM) = Google Cloud (GCP) であれば Google Compute Engine (GCE) であり、 Amazon Web Services (AWS) でいえば Amazon EC2 である

アプリケーションのコードやインフラ設定の変更は人の目によりレビューされ、手動で実施されます。
環境に対する変更は高リスクとみなされ、数週間に一度、もしくは数ヶ月に一度の頻度です。

この段階では、クラウドリソースの展開は手動で行われます。
Google Cloud (GCP) の Deployment Manager や Hashicorp 社の Terraform といったインフラ自動化ツールは用いられません (※) 。
※ Amazon Web Services (AWS) の場合は Terraform や AWS CloudFormation が該当する

Strategic (戦略段階)

  • クラウドリソースはテンプレートから展開する
  • アプリはイミュータブル (※) な VM やコンテナに展開。 OS への接続は不可 (不要)
  • 環境変更のテストは自動
  • 環境変更のリスクは中程度
  • 環境変更は手動

※イミュータブル = 「不変の」を意味する英単語。コード定義の仮想サーバまたはコンテナの利用により、インフラ (サーバ) が不変である代わりにいつでも捨てられることを意味している。従来はサーバを構築すると、内部に配置された設定ファイルにより設定が管理され、アプリケーションのデータを内部に持つため、サーバの中身は「可変」であった。それゆえ、サーバのバックアップを取り、障害の際は中身の復旧が必要となる。対してイミュータブルなインフラでは、サーバの中身は変わらない。データは外部のデータストアに永続化され、設定値はコードでバージョン管理されるからである。障害の際は、障害が起きたサーバ/コンテナは廃棄し、新しいサーバ/コンテナをイメージから復旧する。このイミュータブルなインフラにより管理工数は大幅に減り、水平スケールが容易になる

この段階では VM はイミュータブルな設計になっています。そのためシステム変更におけるスコープを小さくすることに成功しています。
環境設定はファイルではなく、 VM イメージとして保持され (イメージを "焼いておく" と表現することもあります) バージョン管理されています。
ステートフル (※) なワークロードとスケートレス (※) なワークロードは区別されており、そのため柔軟な水平スケール (※) ができるようになっています。

※ ステートフル = アプリケーションやサーバが状態を保持することが前提のアーキテクチャ。「データ腹に持つ」ものが該当。例えばあるアプリケーションサーバがローカルディスクにセッションファイルを保存する仕組みの場合、そのアーキテクチャはステートフルである
※ ステートレス = アプリケーションやサーバが状態を保持 "しない" ことが前提のアーキテクチャ。「データを腹に持たない」ものが該当。保存するべきデータは全てサーバ/コンテナ外部のデータベース等のストレージに保存する
※ 水平スケール = スケールアウトとスケールイン。1つのサーバのスペックを上げたり下げたりするスケールアップやスケールダウンとは対象的に、サーバやコンテナの数を増やしたり減らしたりしてパフォーマンスを調整する方法。アプリケーションがステートレスであれば、データを複製したり整合性を取る必要がないため、水平スケールが容易である

環境変更のリスクは中程度であると認識されている状態です。
本番環境へのデプロイはプログラムにより行われますが、その処理は人手によって起動されます。
必要な場合、すぐにロールバックして元の状態に戻すことができます。

アプリケーションチームは基礎的なモニタリングから卒業し、 Application Performance Monitoring (APM) を実現しています。
24 時間・ 365 日 でアプリケーションのパフォーマンスに関する洞察を、ニアリアルタイムで得ることができています。

Google Cloud (GCP) プロジェクト (あるいは AWS でいう "AWS アカウント" 等) や VPC ・ ID など関連リソースの展開は Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。
コスト明細タグやデータ機密レベル、保有チームなどインプットすべき変数を入力すれば、自動的に展開できるようになっている状態です。

Transformational (柔軟段階)

  • 全クラウドリソースはボタン一つで、数分内に再構築可能
  • アプリはサーバレスなクラウドサービスに展開
  • 環境変更は定常的で低リスク
  • 環境変更はプログラマブルに行われる

本番環境 VM には緊急時のデバッグ目的以外ではアクセスできないようになります。
セルフマネージドなサービス (IaaS) は全て、マネージドサービス、サーバレス、 SaaS などに置き換わっており、運用負荷は最小化されています。

環境変更のリスクは小さいとみなされ、本番環境へのデプロイはプログラムにより自動的に行われます。
カナリアリリース (※) やブルーグリーンデプロイ (※) などのフェイズ別デプロイ戦略が実施されています。

※カナリアリリース, ブルーグリーンデプロイ = いずれもアプリケーションのデプロイ戦略の名称で、新バージョンへの切り替えと問題があった際の旧バージョンへの切り戻しを効果的に行うための戦略。 Amazon Web Services Japan 公開の AWS Black Belt Online Seminar AWS CodeDeploy の資料に詳しい

ロギングとモニタリングは包括的であり各 SLO のもとになる全ての SLI をカバーしています。

全てのクラウドリソースは Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。
本番環境全体が、数分以内で別ゾーンや別リージョンに再構築できるようになっています。

2-2-4. Secure (セキュア)

関連エピック: アクセス管理, データマネジメント , ID (アイデンティティ) 管理

Tactical (戦術段階)

  • ID は Google によってのみ発行
  • Owner, Editor, Viewer といった基本ロールのみ利用 (Google Cloud の場合)
  • 境界型セキュリティに依存し、プライベートネットワーク内を暗黙的に信用してる

この段階では、利用者の ID は Cloud Identity (※) によって管理されており、それが Google Analytics や Adwords, YouTube などの他の Google サービスのアカウントにもなります。
アカウントが企業によって管理されている状態です。
しかしながら、まだ Microsoft Active Directory などの企業の中央ディレクトリとは同期されていません。

※ Cloud Identity = Google Cloud (GCP) の ID を管理するための仕組み。 Amazon Web Services (AWS) の場合は、これを IAM User と読み替えて差し支えない。

Cloud IAM では Owner, Editor, Viewer (※) といった、非常に強い権限を持った基本ロールの利用がほとんどです。
これは、最小権限の原則を守っていない状態といえます。
権限設定がデフォルトのままなので、 Google Cloud (GCP) ユーザーは好きにプロジェクトや請求先アカウントを作成できてしまう状態です。
IAM 権限は Forseti Security のようなツールを使ってモニタリングされていません。
Cloud Audit Logs (※) の管理アクティビティ監査ログやデータアクセス監査ログはシステマティックにチェックされていません。
サービスアカウント (※) の作成も制限なしで自由に作成でき、秘密鍵も自動ローテーションされません。

※ Owner, Editor, Viewer = 管理者用、編集者用、閲覧者用の強い権限を持つロールで、プロジェクト内の全てのリソースに対して強い操作権限を持つ。 AWS であれば Administrator や ReadOnlyAccess といった AWS 定義の IAM ポリシーが該当
※ Cloud Audit Logs = 監査ログを保存する仕組み。 当社ブログ に詳しい。 AWS であれば AWS CloudTrail が該当
※ サービスアカウント = アプリケーションなど人間以外が Google Cloud API 等をコールするときに用いるアカウント。当文の記述は AWS であれば Amazon EC2 用の IAM Role であったりプログラム用の IAM User から発行される Credentials を自由に発行できる状態を意味している

ネットワークセキュリティ (境界型セキュリティ) が過信されており、ファイアウォールが重要なセキュリティコンポーネントです。
IP アドレスやポート番号といった情報に基づいてアクセスが制限されます。
クラウドとオンプレミス間の通信は VPN トンネルなどによる暗号化はなされているものの TLS によるエンドツーエンドの暗号化にはあまり関心が払われていません。
VPC Service Controls (※) は Cloud Storage や BigQuery といったフルマネージドサービスに対して適用されていますが、データの機密性に応じてルールが設計されている状態には達していません。

※ VPC Service Controls = Google Cloud (GCP) の API をコンテキスト情報に応じて保護するための仕組み。 当社ブログ に詳しい。

Strategic (戦略段階)

  • ID は企業のディレクトリから同期される
  • 最小権限の原則に基づいて定義済み IAM Role が利用される (Google Cloud の場合)
  • ネットワークレイヤとアプリケーションレイヤのハイブリッドセキュリティモデル

クラウドユーザーの ID は Active Directory や OpenLDAP といった企業のディレクトリサービスから Google Cloud Identity に同期されているため、整合性があり、運用もシンプルです。
ユーザーは同期されたパスワードで認証するか、あるいはサードパーティの SSO (Single-Sign On) サービスで認証されます。
100% のユーザーは SMS (ショートメッセージ) やワンタイムコード生成アプリを使った二段階認証を使っており、フィッシング攻撃などの対策となっています。

Cloud IAM ポリシーにおいては、おおざっぱな基本ロールの利用はやめて、より細かく権限定義されている事前定義ロール (※) を利用しています。
Google Cloud (GCP) でデフォルトで付与されている プロジェクト作成者 ( Project Creator ) ロールと 請求先アカウント作成者 ( Billing Account Creator ) ロールは Google Cloud 組織レベルからは削除されており基本的なクラウドリソースのガバナンスが確保されています。

※事前定義ロール = 基本ロール以外のプリセットの IAM ロール。例として「 BigQuery 管理者」のように用途別に権限が予め定義されているので利用者は細かく権限を設定する必要がない。 AWS では AWS IAM の「AWS 管理ポリシー」が該当

VPC の境界セキュリティはファイアウォールだけでなく Cloud Load Balancing (TLS 有効化) や Cloud Identity-Aware Proxy (IAP) 、 Cloud Armor などで強化されています。
これらはパブリックなインターネットにサービスを晒すことにおけるリスクを低減化するものです。

Transformational (柔軟段階)

  • 全てのアプリ間アクセスに対して認証・認可が行われる
  • IAM ポリシーが継続的にモニタリングされ修正される
  • インターネットから VPC に至るまでの多層ネットワークセキュリティ

全てのサービス間通信は認証・認可されます。同一 VPC や同じプライベートネットワークにいるノード同士でも、信頼はしません。
VPC のファイアウォールルールも、 IP アドレスレンジによってではなく、サービスアカウントによって許可されます (※) 。

※サービスアカウントによるファイアウォールルール = Google Cloud (GCP) のファイアウォールルールでは、 IP アドレスやポート番号による許可 / ブロックという一般的なルールを使うことができるが、 VM に付与したネットワークタグによるルールや、 VM に付与するサービスアカウントによるルールを利用することもできる

どのデータストアにどのようなデータが入っているか、ということが全体的に理解されており、それゆえに認証をすり抜けたアクセスや不適切なアクセスに対応するセキュリティモデル・データガバナンスモデルを適切に設計することができます。

100% のクラウド利用者がハードウェアセキュリティキーを二段階認証に使っているため、フィッシング攻撃への対策は十分です。
SMS (ショートメッセージ) やワンタイムコード生成アプリが十分に安全ではないと認識されています。

Cloud Audit Logs の管理アクティビティ監査ログやデータアクセス監査ログは定期的に監査され、事前に定義した脅威パターンに一致した場合はアラートが自動発報されるように設定されています。
Cloud IAM の権限やファイアウォールのルールは継続的にモニターされ、 Forseti Security のようなツールで修正されます。

2-3. エピック

クラウド成熟度が測定できたら、次は具体的なアクションです。ここでエピックを使います。
エピックは「人 (People) 」「プロセス (Process) 」「技術 (Technology) 」に分類されています。

Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの

※原文では以降、各エピックはアルファベット順で記載されている。当記事では日本語に翻訳しているが、そのままの順番で記載する。

2-3-1. アクセス管理

目的: 適切な人/サービスだけが認証・認可され適切なリソースに対する適切な操作を行えるようにすること

適切なアクセス管理ができていれば、不便さを感じさせることなく、最小権限の原則で、人/サービスが業務に必要なリソースへアクセスできます。
Google Cloud (GCP) では Cloud Identity と Resource Manager の組み合わせでこれを実現できます。

2-3-2. アーキテクチャ

目的: ベストプラクティスを適切に推奨したり、将来を視野に入れたクラウドコンピューティングやストレージの選択に役立つ視野を提供すること

アプリケーションがクラウドプラットフォームをフル活用できるためにはコンピュートやストレージの適切な選択が必要であり、これに寄与するのがクラウドアーキテクチャです。
例として「柔軟なスケーラビリティを得るためには、アプリケーションはステートレスなマイクロサービス構成とし、永続ストレージとは分離する」「再現性とセキュリティを確保するために、手作業でのパッチ当てやメンテナンスを排除する。そのためインフラはコード定義とし、イミュータブルなものにする」といったものです。

アプリケーションやデータウェアハウス、パイプラインなどのスケーラビリティ・可用性・費用負担を段階的に変えていくこと、また開発スピードを向上させていくことは、どのようなビジネスでも必須だと考えられます。

2-3-3. 振る舞い

目的: よりチームとして働きやすくしたり、受け手の気持ちを考えるコミュニケーションを取れるようにしたり、スキル向上プログラムからより多くを得たりするための「振る舞い」を助長する、システマティックな方法を開発すること

人の振る舞いの 90% 以上は無意識のモチベーション、価値観、信念、習慣から起こるのだといいます。
成功するクラウド導入には、意識的な行動だけでなく、マインドセットや価値観にも着目する必要があります。
Learn (学習) や Lead (リード) がうまくいくかどうかは、人々が次のような新しい振る舞いを受け入れられるかどうかにかかっています。
例: コラボレーション、批判しない文化、心理的安全性、プロトタイピング、データドリブンな意思決定

組織の「現在の振る舞い」と「目指すべき振る舞い」の両方を理解して、「目指すべき振る舞い」に行き着くための行程を設計することが最終ゴールです。

2-3-4. CI/CD (Continuous integration and delivery)

目的: CI/CD パイプラインによりシステムへの変更を自動化し、最小の中断時間で全ての変更がテストされ、監査され、デプロイされるようにすること

巨大な分散システムでは不明点や依存関係、部分によって責任部署が違うなど、コードへの変更が意図通りに動かない可能性に繋がる不確定要素が多くなりがちです。
ビジネスにとって、不確定要素はリスクやソフトウェアデリバリーの遅延に繋がります。
CI/CD (Continuous integration and delivery) によって継続的にリリースプロセスを検証することで、どんなコード変更でも意図通りに動くという自信に繋がります。

2-3-5. コストコントロール

目的: コストをニアリアルタイムで可視化することで、開発者やアーキテクトにコスト意識を持たせること

クラウドでは前払いが必要な調達がなく、資産化による減価償却に基づく複数年のキャパシティ計画もありません。そのため、コストコントロールは一人のソフトウェアエンジニアから始まることもあります。
オンプレでは物理的な制約がありましたが、クラウドでは代わりにリソースクォータ (ソフトウェア的な上限) やオートスケーリングの設定があるのみです。
適切なダッシュボード・アラート設定・プロセスの確立がなければ、複数プロジェクト・複数チーム・複数事業部門によるクラウド支出を管理することは、難易度が高く時間もかかるものとなってしまいます。

物理的制約がないため、アプリケーションの所有部門は、次の3つの戦略のうちどれかを選び、実行する必要があります。

  • 無制限のスケーリング (例: E コマースサイト)
  • 徐々に削減する (例: 社内のデータ分析)
  • 上限を設ける (例: 開発用サンドボックス)

2-3-6. コミュニケーション

目的: 「失敗をオープンに共有することを推奨」「ミスは改善の機会として歓迎される」といった風潮の土台となるように、批判をしない文化やオープンコミュニケーションの文化を理解して、醸成すること

こんにちではソフトウェアのデリバリーは速度も速く、複雑です。そのような中で組織は、失敗や障害は不可避であり、ミスは改善の良い機会である、ということを理解する必要があります。
心理的安全性を作り出し、批判のない職場を醸成し、リスク取ることが奨励され、ミスの責任は個人ではなく仕組みやプロセスにあるとする文化であることは、もはや必須です。
またポストモーテム (前述) は、批判しない文化・学び続ける文化・仕組みの改善の文化を醸成する大事なツールとなります。

2-3-7. データマネジメント

目的: どんなデータが保管されており、出自はどこで、どれくらい機密性があり、誰がアクセス可能なのか、といったことを理解して管理することで、データの安全を守り、検索可能で、利用可能にすること

データマネジメントが弱いと、データ漏洩やそれによる信頼失墜、規制当局による制裁などの結果に繋がります。
暗号化、分類、漏洩対策、コンプライアンス規格の順守などはもちろんのこと、データマネジメントでは他にも多くの事項を検討する必要があります。

2-3-8. 外部の知見

目的: エキスパートの支援により、ベストプラクティスを適用し、他組織のクラウド導入期の教訓を学ぶことで、クラウド導入を加速すること

知識はトレーニングなどから得ることができます。しかし経験はそうもいきません。
そういった経験があれば、問題を早急に解決したり、予測不可能なリスクに対処したり、特定のビジネスニーズにフィットするソリューションを効率的に開発することができます。
クラウド導入の初期段階では、組織の外部に支援を求めることが有効な策となり得ます。
Google のパートナー、プロフェッショナルサービス (※) 、 Office of the CTO (※) 、ソリューションアーキテクト (※) などが支援可能です。

※プロフェッショナルサービス、 Office of the CTO = いずれも Google Cloud のコンサルタントサービス
※ソリューションアーキテクト = クラウドでのアーキテクチャ設計に精通したエンジニア

2-3-9. ID (アイデンティティ) 管理

目的: 人もしくはサービスへの信頼ある認証を提供すること、および認証情報の漏洩やなりすましに対策すること

人やデバイスのアイデンティティ管理に信頼がおけることは、現代的なセキュリティモデルでは必須です。
現代的なセキュリティモデルにおいては、単一要素だけを信頼することはありません。
パスワード、証明書、 IP アドレスといった要素は単一では信頼の対象にはなり得ません。
代わりに複数要素を組み合わせることで、どんなネットワークからのアクセスも可能にします。

2-3-10. インシデント管理

目的: 内製および Google のサポートのもとで、予定外のサービス低下を、秩序正しく迅速に、アラート発報・トリアージ・整理すること

システム運用では効率的で効果的なサポート提供や、迅速なサービス復旧が求められます。
クラウド導入においては、スキルのギャップや運用プロセスのギャップが発生し得ます。
ソリューションの最適化や稼働率向上、ビジネス価値を確保するためには、これらのギャップは正す必要があります。

適切なサポート体制を構築することで、サービス中断のリスクを下げたり、中断が起こったときでも影響範囲を最小化したりすることができます。
ツールやサービス構築に使っているプラットフォームを最大限利用することが重要です。

2-3-11. Infrastructure as Code (IaC, インフラのコード化)

目的: 設定値や構築をコード化することで自動化し、人的ミスを撲滅し、時間を節約し、全ステップをドキュメント化すること

インフラをプログラム化することにより設定値とリソースの展開を自動化すれば、水平スケール・自動スケールが可能になります。
またサーバへの admin/root 権限アクセスを禁止したり、開発環境を数分で展開したり、本番環境すら安定バージョンと新バージョンの間をダウンタイムなしで切り替えることも可能になります。

2-3-12. 計測

目的: リソースの稼働状況やログイベントを計測し、アプリケーションをトレース・プロファイリング・デバッグすることで、様々な状況下でのシステムの挙動を監視し、 SLO を定量化すること

包括的な計測を行うことは、クラウドでは一層重要になります。
計測されたメトリクス (指標) によって、クラウドリソースをいつ、どのようにスケールするかが決まりますし、障害時やパフォーマンス低下時には、原因がクラウドサービス側なのかアプリケーション側なのかを判断する重要な要素になります。
また、クラウドにおける全ての操作は API コールなので、誰が、どのリソースに対して、どのような操作を行ったかという監査ログを包括的かつ変更不可能な形で残すことで、クラウド運用を本質的にセキュアにすることができます。

2-3-13. ネットワーキング

目的: 認証・認可の有無とは別軸で、サービスやデータの流れを論理的境界により接続・保護すること

ネットワークはどのようなビジネスにとっても重要なインフラです。ネットワークは顧客とサービスを繋ぎ、エンドユーザーとビジネスを繋ぎ、従業員の仕事を可能にします。
こんにちのビジネスは、接続性なしには成り立ちません。そして接続性は、組織 (会社) の境界内だけにとどまらず、顧客、パートナー企業、インターネットにも広げる必要があります。
これはどのような規模・形式のビジネスでも同様であり、オンプレミス・クラウド・ハイブリッドの別を問いません。

2-3-14. 人的オペレーション

目的: 必要な組織構成を定義し、クラウド導入担当者たちを適切な役職・スキル・勤務評定手法に当てはめ、クラウド導入の円滑を図ること

組織構成・人員配置・勤務評定手法を調整することで、チームが変更を受け入れて新しい役割をこなすことを促進できます。
逆に、 IT 部門や運用部門、関連ビジネス部門がどのように動くべきかを理解せず、期待されていることが分からない状態だと混乱が発生し、せっかくのクラウド移行のための投資への悪影響となってしまいます。

また、クラウド導入担当者たちが新しい役割や新しい振る舞い (コラボレーション、透明性、失敗の許容、信頼) を受け入れることへの動機付けも重要です。
そのための勤務評定手法やインセンティブ構成が必要となってきます。

最後に、測定可能でありかつクラウド導入行程と連携した「組織としてのゴール」を定義することが非常に重要です。
ゴールや方向付けがブレると、クラウド導入の成功は遠のきます。

2-3-15. リソース管理

目的: クラウド環境の整頓・一貫性確保・制御のため、クラウドリソースのクォータ (割当て上限) を整理・明示・設定すること

クラウドでは誰でも仮想的にリソースを生成することができますが、代わりに見通しが悪くなったり、勝手な行動をされるおそれも出てきます。
有用で分かりやすいルールを作り、組織の階層構造と合わせてフォルダー・プロジェクトの階層構造 (※) を構築すれば、ガバナンスを維持し、無秩序状態を回避することができます。

※フォルダー・プロジェクトの階層構造 = Google Cloud (GCP) ではクラウド環境の1テナントを "プロジェクト" と呼び、複数プロジェクトをグルーピングして整理する単位を "フォルダー" と呼ぶ。フォルダーやプロジェクトは階層構造にして管理ポリシーや IAM 権限を適用できる

2-3-16. スポンサーシップ

目的: 幹部層からの熱心かつ継続的な支援により、クラウド導入担当者が変革を委任されていることを広く認識させること

スポンサーシップとは、幹部やリーダーがクラウド導入チームやプロジェクトに対して、能動的で目に見える形の支援を行うことをいいます。
組織でのクラウド導入は複雑です。ビジネス価値の増大やコラボレーション推進、速度向上のために、組織規模でクラウド利用を決断するにあたって、 強力なスポンサーシップは必要不可欠です。

幹部層は組織で最も影響力がある立ち位置だけに、クラウド導入戦略に対して熱心かつ継続的な支援を行うことで、クラウド導入担当者たちが変革を委任されているのだということを広く認識させる必要があります。

2-3-17. チームワーク

目的: クラウド技術が最高効率で活用されるよう、コラボレーションと信頼に基づく振る舞い・文化を体現するチームを構築すること

チームワークは、個々人の担当者によるボトムアップの理念リーダーシップ (Thought leadership) から始まります。
理念リーダーシップは Center of Excellence (CoE ※) や専任エバンジェリスト、非公式のクラウド派など様々な形を取り、また多くの知見共有の取り組みとなっている場合があります。

※ Center of Excellence (CoE) = 組織の中で特定技術や分野において、研究・開発・導入などのリーダーシップを取るチームのこと。特にクラウドにおいては Cloud Center of Excellence (CCoE) と呼ばれ近年話題になっている

こういった主導者たちが、セキュリティやアーキテクチャ、ネットワーク、運用、データベース管理などの規律を形作っていきます。
彼らに共通しているのは、前向きであることと、クラウド導入のベストプラクティスに自発的に関心を持っていることです。

こういった主導者がいない場合、クラウド導入は幹部層のスポンサーシップに依存してしまいます (スポンサーシップの項を参照)。しかしこのような一方的かつトップダウンの方策はスケールが遅く、またクラウドの利点である IT リソースの本質的な民主化という利点を活用できない結果にお話ある可能性があります。

2-3-18. スキル向上

目的: 現職メンバーが持つ業務知識や既存 IT 資産に関する知見と、新規に学んだベストプラクティスを融合するため、学習に対して投資をすること

クラウドコンピューティングは、仮想化の出現以来、類を見ないパラダイムシフトとなっています。
これらの新しい考え方やベストプラクティスは、チームの個々人のスタイルにあうように、様々な方法で学習することができます。先生が教えるタイプの研修や、 coursera.com や qwiklabs.com のようにインタラクティブな自己学習タイプのものでもよいでしょう。

スキル向上とは、技術的な理論を学ぶことだけを指すのではありません。学んだことを業務に活かしたり、自分で問題解決ができるようにしたり、 Google サポートを利用したり、同僚と教訓を共有したりすることで、継続的に学ぶ文化を醸成し、それにより組織全体の知見を育てることこそが重要です。

付録: クラウド成熟度アセスメント

ホワイトペーパーの抄訳は、以上で終了です。
ここからは Google により無償公開されている、クラウド成熟度アセスメントツールをご紹介します。
以下のサイトで公開されている Web ツールを用いると、ホワイトペーパー内でも紹介されていたクラウド成熟度を測定することができます。

digitalmaturitybenchmark.withgoogle.com

画面に表示される質問に順に答えていくと、組織の現在のクラウド成熟度を4つのテーマに沿って測定することができます。
質問の内用を吟味すると、今の組織に足りないものが何か、見えてくるはずです。
質問は英語ですので、苦手な方は Chrome ブラウザの翻訳機能などを駆使してご活用ください。

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。