Google Cloud アーキテクチャ フレームワークは、アーキテクト、デベロッパー、管理者、およびその他のクラウドの実務担当者が、安全で効率的、復元性が高く、高パフォーマンスで費用対効果に優れたクラウド トポロジを設計および運用するためのベスト プラクティスと最適化案を提供します。Google Cloud アーキテクチャ フレームワークは、Google Cloud による適切に設計されたフレームワークです。
Google の複数の部門にまたがるエキスパートのチームが、アーキテクチャ フレームワークを構成する設計の最適化案とベスト プラクティスを検証します。チームがアーキテクチャ フレームワークをキュレートし、Google Cloud の拡張機能、業界のベスト プラクティス、コミュニティの知識、ユーザーからのフィードバックを反映させます。主な変更の概要については、最新情報をご覧ください。
アーキテクチャ フレームワークの設計ガイダンスは、クラウド用に構築されたアプリケーションと、オンプレミスから Google Cloud に移行されたワークロード、ハイブリッド クラウドのデプロイメント、マルチクラウド環境に適用されます。
アーキテクチャ フレームワークのカテゴリ
次の図に示すように、Google Cloud アーキテクチャ フレームワークは 5 つのカテゴリ（柱）に編成されています。
- オペレーショナル エクセレンス
- クラウド ワークロードを効率的にデプロイ、運用、モニタリング、管理します。
- セキュリティ、プライバシー、コンプライアンス
- クラウド内のデータとワークロードのセキュリティを最大化し、プライバシーを考慮した設計を行い、規制要件と標準に対応します。
- 信頼性
- クラウドで復元性と高可用性を備えたワークロードを設計し、運用します。
- 費用の最適化
- Google Cloud への投資のビジネス上の価値を最大化します。
- パフォーマンスの最適化
- パフォーマンスが最適化されるようにクラウド リソースを設計、調整します。
基本原則
アーキテクチャ フレームワークの各カテゴリで推奨事項を確認する前に、次の基本原則を確認してください。
変化に対応する設計
静的なシステムはありません。ユーザーのニーズ、システムを構築するチームの目標、システム自体は常に変化しています。変更の必要性を念頭に置いて、チームが定期的に小規模な変更を配布し、その変更について迅速にフィードバックを取得できるように、開発プロセスと本番環境プロセスを構築します。変更をデプロイする能力を常に示すことは、システムを担当するチームやシステムのユーザーなどのステークホルダーと信頼関係を築くうえで役立ちます。DORA のソフトウェア デリバリーの指標を使用すると、システムの変更の速度、容易さ、安全性をモニタリングできます。
アーキテクチャの文書化
ワークロードのクラウドへの移行やアプリケーションの構築を開始する際に、システムに関するドキュメントが不足していることが大きな障害となる場合があります。現在のデプロイのアーキテクチャを正しく可視化するには、ドキュメントが特に重要です。
質の高いドキュメントは、ドキュメントの量ではなく、システムの変更に応じて明確で有用な内容を維持することで実現できます。
クラウド アーキテクチャを適切に文書化することで、共通の言語と標準が確立され、部門横断的なチーム間でのコミュニケーションとコラボレーションを効果的に行いやすくなります。また、将来的な設計上の意思決定を促し、指針にするために必要な情報も提供します。設計上の意思決定に対応する内容を提供するため、ユースケースを念頭に置いてドキュメントを作成する必要があります。
時間の経過とともに、設計上の意思決定は進化、変化していきます。変更履歴があれば、チームが構想を調整し、重複を避け、時間の経過に沿ったパフォーマンスの変化を効果的に測定するために必要な背景情報が得られます。現在の設計、戦略、過去の経緯をよく理解していない新しいクラウド アーキテクトをオンボーディングする場合、変更ログは特に役立ちます。
DORA による分析で、ドキュメントの品質と組織のパフォーマンス（組織のパフォーマンス目標と収益性目標を達成する能力）の間に明確な関連性があることが判明しました。
設計を簡素化し、フルマネージド サービスを利用する
設計にはシンプルさが重要です。アーキテクチャが複雑すぎて理解しにくい場合、設計を実装して時間の経過とともに管理することが難しくなります。可能であれば、フルマネージド サービスを使用して、ベースライン システムの管理とメンテナンスに伴うリスク、時間、労力を最小限に抑えてください。
本番環境ですでにワークロードを実行している場合は、マネージド サービスでテストして、運用の複雑さがどのように軽減されるかをご確認ください。新しいワークロードを開発している場合は、単純なものから最小実装製品（MVP）を確立して、オーバー エンジニアリングへの抵抗感を和らげてください。特殊なユースケースを特定し、イテレーションを行い、時間をかけて段階的にシステムを改善していくことができます。
アーキテクチャを分離する
DORA の調査によると、アーキテクチャは継続的デリバリーを達成するための重要な予測要素です。分離とは、アプリケーションやサービス コンポーネントを、独立して動作できる小さなコンポーネントに分離するために使用される手法です。たとえば、モノリシック アプリケーション スタックを個別のサービス コンポーネントに分離できます。疎結合アーキテクチャでは、さまざまな依存関係に関係なく、アプリケーションで機能を個別に実行できます。
アーキテクチャを分離することで、柔軟性が向上し、次のことが可能になります。
- 独立したアップグレードを適用する。
- 特定のセキュリティ管理を実施する。
- サブシステムごとに信頼性の目標を設定する。
- 正常性をモニタリングする。
- パフォーマンスとコストのパラメータをきめ細かく制御する。
分離プロセスは、設計の早い段階から始めることも、規模の拡大に伴うシステム アップグレードの一部として行うこともできます。
ステートレス アーキテクチャを使用する
ステートレス アーキテクチャでは、アプリケーションの信頼性とスケーラビリティの両方を向上させることができます。
ステートフル アプリケーションは、ローカル キャッシュのデータなど、さまざまな依存関係を使用してタスクを実行します。ステートフル アプリケーションでは、多くの場合、進捗状況をキャプチャして正常に再起動するための追加のメカニズムが必要です。ステートレス アプリケーションは、共有ストレージやキャッシュ サービスを使用することで、ローカルの依存関係をさほど利用することなくタスクを実行できます。ステートレス アーキテクチャを使用すると、ブート依存関係を最小限に抑え、アプリケーションを迅速にスケールアップできます。アプリケーションは強制的な再起動に耐え、ダウンタイムを短縮し、エンドユーザーのパフォーマンスを高めることができます。