アーキテクチャ フレームワークの原則に沿ったシステム設計の最適化
Google Cloud Japan Team
※この投稿は米国時間 2021 年 12 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。
お客様が Google Cloud を使用してビジネスを成功に導けるよう、Google は、Google Cloud アーキテクチャ フレームワークを公開しました。これは、セキュアで効率性と復元力が高く、高性能で費用対効果の高い、ワークロード構築と運用のための一連の正規ベスト プラクティスです。
今日は、アーキテクチャ フレームワークのシステム設計の柱について、システム設計の 4 つの重要原則と Google のドキュメントに対する最近の改善内容を含めて、より深く掘り下げていきます。また、Google Cloud コミュニティに新たに設けられたアーキテクチャ フレームワーク専用のスペースについてもご紹介します。このスペースは、協力的で知識の豊富な仲間、Google 社員、プロダクト エキスパートからなるグローバルなコミュニティとともに、お客様の目標達成を支援するために設けられました。
システム設計とは？
システム設計の柱とは、アーキテクチャ フレームワークの基礎となる柱であり、Google Cloud のプロダクト、機能、設計原則を含み、ビジネスとシステムの要件を満たすために必要なアーキテクチャ、コンポーネント、データを定義するのに役立ちます。
システム設計のコンセプトと推奨事項は、アーキテクチャ フレームワークの他の 5 つの柱、「卓越した運用」、「セキュリティ、プライバシー、コンプライアンス」、「信頼性」、「費用の最適化」、「パフォーマンスの最適化」にも適用できます。
システム設計の柱で提示されているガイダンスに照らして、アーキテクチャの現状を評価し、潜在的なギャップや改善すべき箇所を特定できます。
システム設計の基本原則
堅牢なシステム設計とは、安全性、信頼性、拡張性、独立性を備えたものであり、変更を一度ですべてに適用し、潜在的なリスクを最小限に抑え、運用効率を向上させることができます。堅牢なシステム設計を実現するには、以下の 4 つの基本原則に沿って実行することをおすすめします。
すべてを文書化する
お客様がクラウドへの移行を検討されている場合や、アプリケーションの構築を開始される場合に成功の大きな妨げとなるのが、文書の不足です。特に、現在のアーキテクチャのデプロイを正しく可視化した文書が不足しがちです。
クラウド アーキテクチャを適切に文書化することで、共通の言語と標準を定め、部門横断的なチーム間でのコミュニケーションとコラボレーションを効果的に行いやすくなります。また、この文書化により、クラウドの効果的な利用を促進するため、将来的な設計上の意思決定を促し、これを推進するために必要な情報も得られます。
時間の経過とともに、設計上の意思決定が増え、変化していきますが、変更履歴があれば、チームが構想を調整し、重複を避け、時間の経過に沿ったパフォーマンスの変化を効果的に測定するために必要な背景情報が得られます。変更ログは、現行システムの設計、戦略、履歴に精通していない新しいクラウド アーキテクトを迎え入れるときに、特に重要な役割を果たします。
設計を簡素化する（フルマネージド サービスを利用する）
システム設計においては、シンプルさが重要となります。アーキテクチャが複雑すぎて理解できない場合、デベロッパーと運用チームがシステム導入時や現在継続中の管理において面倒な問題に直面する可能性があります。可能な限り、フルマネージド サービスを利用して、基本システムの管理と保守のリスク、およびチームが必要とする時間と労力を最小限に抑えることを強くおすすめします。
すでに本番環境でワークロードを運用している場合は、マネージド サービスを試しに利用することで、複雑な運用を簡素化できます。新規にシステムを導入する場合は、シンプルに始め、MVP を確立し、さまざまな機能を取り入れたい衝動を抑えましょう。特殊なユースケースを特定し、イテレーションを行い、時間をかけて段階的にシステムを改善していくことができます。
アーキテクチャを分離する
分離とは、モノリシック アプリケーション スタックなどのアプリケーションやサービス コンポーネントを、独立的に動作する小さなコンポーネントに分ける手法をいいます。したがって、分離されたアーキテクチャは、さまざまな依存関係があるにもかかわらず、独立して機能できます。
アーキテクチャを分離することで、独自のアップグレードの適用、特定のセキュリティ対策の適用、信頼性目標の設定、健全性のモニタリング、パフォーマンスと費用の細かいパラメータ制御をより柔軟に行えます。
分離は、設計段階早期から始めることも、規模の拡大に伴うシステム アップグレードの一部として行うこともできます。
ステートレス性を活用する
ステートフル アプリケーションは、タスクを実行するために、ローカルにキャッシュされたデータなどのさまざまな依存関係を利用し、多くの場合、進捗状況の把握、再起動後のデータの維持などをするための追加の仕組みを必要とします。
一方、ステートレス アプリケーションは、共有ストレージやキャッシュ サービスを利用することで、ローカルの依存関係をさほど利用することなくタスクを実行できます。これにより、アプリケーションは最小限のブート依存関係を利用するだけで迅速にスケールアップでき、強制的再起動に耐え、ダウンタイムを削減し、エンドユーザーへのサービス パフォーマンスを最大限に高めることができます。
システム設計の柱では、アプリケーションをステートレスにするための推奨事項、すなわちステートフル アプリケーションのためのマシン状態の取得を改善するためにクラウドネイティブの機能を利用する方法について説明しています。
他の柱に適用されるシステム設計の原則
システム設計の基本原則は、卓越した運用、セキュリティ、信頼性、費用、パフォーマンスの最適化など、アーキテクチャ フレームワークの他の 5 本の柱にも適用できます。ここでは、システム設計の基本原則が実際にどのようなものか、以下に例を示します。
フルマネージドの、可用性の高い運用ツールを使用してワークロードをデプロイ、モニタリングする。これにより、ワークロードの維持と最適化にかかる運用上のオーバーヘッドを最小限に抑えることができます。
コンポーネント レベルでセキュリティ対策を行う。コンポーネントを分離することで、きめ細かな管理対策を適用し、効果的なコンプライアンス管理を行うとともに、セキュリティ上の潜在的な脆弱性の影響範囲を最小限に抑えることができます。
高可用性と高いスケーラビリティを念頭に置いた設計を行う。アーキテクチャを分離することにより、きめ細かな信頼性目標を定義、管理できます。これによって、重要性の高いサービスの耐久性、スケーラビリティ、可用性を最大限に高めると同時に、重要性が高くないコンポーネントを必要に応じて最適化することが可能になります。
予算を決め、費用対効果を考慮した設計を行う。通常、信頼性の目標を定義するときは、費用が重要な要素となります。そのため、アプリケーションの設計時には、早い段階でさまざま費用指標を考慮することが重要です。アーキテクチャを分離することで、きめ細かな費用の予算設定と管理を行うことができ、これによって運用効率を向上させ、費用の最適化を図ることができます。
最良のスピードとパフォーマンスを求めて設計を最適化する。費用予算内でサービス可用性を設計するときは、パフォーマンス指標も考慮するようにしてください。さまざまな運用ツールを使用することで、パフォーマンスのボトルネックを把握し、パフォーマンスの効率化を図ることができます。
これらはほんの一例ですが、システム設計の原則が、アーキテクチャ フレームワークの他の 5 本の柱において、他のさまざまなユースケースにも拡張できることがおわかりいただけると思います。
Google Cloud コミュニティの一部となったアーキテクチャ フレームワーク
Google Cloud コミュニティは、Google Cloud ユーザーが質問して答えを見つけ、積極的に参加して有意義な関係を築き、アイデアを共有してプロダクト ロードマップに影響を与え、さらに新しいスキルについて学んで専門知識を身につけるための、革新的で信頼できる、活気に満ちた交流の場です。
本日は、Google Cloud コミュニティにアーキテクチャ フレームワーク専用の新しいスペースが開設されたことをお知らせします。このスペースでは、以下を行えます。
実践的な手引きを示し、システム設計の柱に関連する具体的な質問や課題を取り上げた、正規の記事を読むことができます。今後、残りの 5 本の柱に焦点を当てた記事を公開していく予定です。
メンバーが質問したり、回答を得たりできる自由な議論の場に参加できます。
「Ask Me Anything（なんでも聞いて）」シリーズなどのコミュニティ イベントに参加できます。同シリーズでは、Google がアーキテクチャ フレームワークの特定のトピックに関するバーチャル ウェブセミナーを開催し、参加者からの質問を受け付けます。
Google Cloud コミュニティとアーキテクチャ フレームワークは、協力的で知識豊富な仲間、Google 社員、プロダクト専門家からなるグローバル コミュニティとともに、お客様が目標を達成するための信頼できる場を提供します。
今すぐ Google Cloud コミュニティの新しいスペースにアクセスし、まだメンバー登録をされていない方は、ぜひメンバー登録を行って、あらゆる機会をご活用ください。
システム設計 2.0 の変更点
今年初め、Google は、アーキテクチャ フレームワークの最新版（2.0）をリリースしました。また、世界中のパートナーとお客様、Google プロダクト エキスパートのチームからのフィードバックをもとに、Google が持つ一連のベスト プラクティスを強化し続けています。
システム設計の柱における変更点を以下に紹介します。
リソースのラベルとタグのベスト プラクティスが追加され、リソース管理が容易になりました。
コンピューティング セクションは、コンピューティング ワークロードの選択、設計、運用、スケーリングに焦点を当てて再編成されました。
データベース セクションは、データベース ワークロードの選択、移行、運用などのトピックに再編され、ワークフロー管理に関するベスト プラクティスに焦点を当てています。
データ分析セクションには、データ ライフサイクル、データ処理、トランスフォーメーションのセクションが追加されました。
人工知能（AI）と機械学習（ML）に関する新しいセクションが追加され、ML ワークロードのデプロイと管理に関するベスト プラクティスを取り扱っています。
今後も、Google Cloud をご利用のお客様がビジネスを成功に導けるようサービスを改善し、お客様を支援できるよう、お客様からのご意見をお待ちしております。
Google Cloud コミュニティのサイトでアーキテクチャ フレームワークの開催に協力してくれた Andrew Biernat、Willie Turney、Lauren van der Vaart、Michelle Lynn、Shylaja Nukala に感謝します。また、Minh "MC" Chung、Rachel Tsao、Sam Moss、Nitin Vashishtha、Pritesh Jani、Ravi Bhatt、Olivia Zhang、Zach Seils、Hamsa Buvaraghan、Maridi Makaraju、Gargi Singh、Nahuel Lofeudo には、システム設計のコンテンツをうまく立ち上げるうえで協力してくれました。
- アーキテクチャ フレームワーク担当ソリューション エンジニア / プロジェクト リーダー Omkar Suram
- Google Cloud ソリューション アーキテクチャ担当ディレクター Rob Rosen
