システム設計の基本原則

Last reviewed 2023-08-05 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、システム設計の基本原則について説明します。堅牢なシステム設計とは、安全性、信頼性、拡張性、独立性を備えたものです。これにより、システムを停止することなく、反復と取り消しが可能な変更を行い、潜在的なリスクを最小限に抑え、運用効率を向上させることができます。堅牢なシステム設計を実現するには、以下の 4 つの基本原則に沿うことをおすすめします。

すべてを文書化する

ワークロードのクラウドへの移行やアプリケーションの構築を開始する際に、システムのドキュメントが不足していることが成功を妨げる主な要因となります。現在のデプロイのアーキテクチャを正しく可視化するには、ドキュメントが特に重要です。

クラウド アーキテクチャを適切に文書化することで、共通の言語と標準が確立され、部門横断的なチーム間でのコミュニケーションとコラボレーションを効果的に行いやすくなります。また、将来的な設計上の意思決定を促し、指針にするために必要な情報も提供します。設計上の意思決定に対応する内容を提供するため、ユースケースを念頭に置いてドキュメントを作成する必要があります。

時間の経過とともに、設計上の意思決定は進化、変化していきます。変更履歴があれば、チームが構想を調整し、重複を避け、時間の経過に沿ったパフォーマンスの変化を効果的に測定するために必要な背景情報が得られます。現在のシステム設計、戦略、過去の経緯をよく理解していない新しいクラウド アーキテクトをオンボーディングする場合、変更ログは特に役立ちます。

設計を簡素化し、フルマネージド サービスを利用する

システム設計にはシンプルさが重要です。アーキテクチャが複雑すぎて理解しにくい場合、設計を実装して時間の経過とともに管理することが難しくなります。可能であれば、フルマネージド サービスを使用して、ベースライン システムの管理とメンテナンスに伴うリスク、時間、労力を最小限に抑えてください。

本番環境ですでにワークロードを実行している場合は、マネージド サービスでテストして、運用の複雑さがどのように軽減されるかをご確認ください。新しいワークロードを開発している場合は、単純なものから最小実装製品（MVP）を確立して、オーバー エンジニアリングへの抵抗感を和らげてください。特殊なユースケースを特定し、イテレーションを行い、時間をかけて段階的にシステムを改善していくことができます。

アーキテクチャを分離する

分離とは、アプリケーションやサービス コンポーネントを、独立して動作できる小さなコンポーネントに分離するために使用される手法です。たとえば、モノリシック アプリケーション スタックを個別のサービス コンポーネントに分割できます。分離されたアーキテクチャでは、さまざまな依存関係に関係なく、アプリケーションは機能を個別に実行できます。

アーキテクチャを分離することで、柔軟性が向上し、次のことが可能になります。

  • 独立したアップグレードを適用する。
  • 特定のセキュリティ管理を実施する。
  • サブシステムごとに信頼性の目標を設定する。
  • 正常性をモニタリングする。
  • パフォーマンスとコストのパラメータをきめ細かく制御する。

分離は、設計段階早期から始めることも、規模の拡大に伴うシステム アップグレードの一部として行うこともできます。

ステートレス アーキテクチャを使用する

ステートレス アーキテクチャでは、アプリケーションの信頼性とスケーラビリティの両方を向上させることができます。

ステートフル アプリケーションは、ローカルのキャッシュに保存されたデータなど、さまざまな依存関係を使用してタスクを実行します。ステートフル アプリケーションでは、多くの場合、進捗状況をキャプチャして正常に再起動するための追加のメカニズムが必要です。ステートレス アプリケーションは、共有ストレージやキャッシュ サービスを使用することで、ローカルの依存関係をさほど利用することなくタスクを実行できます。ステートレス アーキテクチャを使用すると、ブート依存関係を最小限に抑え、アプリケーションを迅速にスケールアップできます。アプリケーションは強制的な再起動に耐え、ダウンタイムを短縮し、エンドユーザーのパフォーマンスを高めることができます。

システム設計のカテゴリでは、アプリケーションをステートレスにするための推奨事項、すなわちステートフル アプリケーションのためのマシン状態の取得を改善するためにクラウドネイティブの機能を利用する方法について説明しています。

次のステップ