ソリューション アーキテクトの基礎
すべてのワークロードは、コンポーネントとトポロジの設計プロセスを通過します。 このプロセスは、初期要件とワークロードの長期的成功のための設計が行われるワークロードの開始時に最も負荷が高くなります。 また、アーキテクチャの設計は、時と共にワークロードが変化し、組織が機能を追加、変更、または削除する際にも行われます。
アーキテクトの主な役割は、コンポーネントとトポロジの設計を行うことです。 クラウドベースおよびハイブリッド ソリューションを専門とするアーキテクトは、一般に "クラウド ソリューション アーキテクト" と呼ばれます。 一部の組織では、クラウド ソリューション アーキテクトは、エンタープライズ アーキテクチャ グループ内の一元化された権限内に存在します。 また、特定のワークロードを専門とする場合もあります。
アーキテクトの役割は、専用のロールに担わせることができます。 場合によっては、信頼できる技術スペシャリスト (ワークロード エンジニアリング リードなど) がアーキテクトの役割を担うこともあります。 または、組織によっては、ワークロードに関係するシニア エンジニアの小集団に役割を分散させる場合もあります。
アーキテクトは通常、システム設計以外のロールも経験しています。 以下が考えられます。
- 開発者や運用チームのメンバーだったことがある。
- カスタマー サポート チームと連携したことがある。
- システムの品質保証テストやユーザー受け入れテストの方法を理解している。
- ディザスター リカバリーの訓練やインシデント レスポンスを行なったことがある。
- ワークロード機能の追加変更と大規模変更を両方経験したことがある。
- 仕様やユーザー受け入れ条件を解釈したことがある。
上記のリストはすべてを網羅するものではありませんが、これらの視点はアーキテクトが設計業務にもたらす重要な側面の 1 つです。 Azure Well-Architected Framework は、ガイダンスを最も効果的に活用するため、これらが実践されていることを前提としています。
次のセクションでは、アーキテクトがその役割を効果的に発揮するために従うべき基本原則について説明します。
意思決定フレームワークを持つ
設計の重要な側面の 1 つは、一貫したプロセスを用いて意思決定を行うことです。 アーキテクトは、初期設計と増分設計の両方に厳格に取り組む必要があります。
予想される意思決定事項を特定します。 学習したエクスペリエンスを元に、意思決定事項を特定します。 予定される意思決定事項のすべてをログに記録します。
情報に基づいた意思決定を行います。 制限、制約、トレードオフ、労力、可逆性、リスクを考慮します。 技術文書やガイダンスと共に、概念実証の裏付けとなる証拠を含めます。
アーキテクチャ決定レコード (ADR) に意思決定を記録します。 意思決定事項と共に、その根拠を文書化します。
実装をフォローアップします。 すべての意思決定事項を伝達し、実装します。 実装から学習し、将来の意思決定に役立てます。 意思決定事項を特定できなかったことでリスクが生じた領域を探します。
クラウド設計パターンを知る
クラウド設計パターンは、アーキテクチャの基本的な構成要素です。 クラウドベースのアーキテクチャやアプリケーションの設計は、多くの場合、パターン認識の演習になります。
ワークロードの機能要件と非機能要件を評価して、パターンを認識します。 標準化されたパターンから、設計をユース ケースにマップする機会を探します。
先見性を持つ
現時点の要件を満たす設計を行うことは不可欠ですが、ワークロードの進化を予測することもアーキテクトにとって重要です。 実装されたシステムに変更を組み込むには、実装前に設計を変更するよりもコストがかかります。
計画された運用終了時期まで使用に耐えるシステムを設計するには、アーキテクチャの柔軟性を念頭に置いてワークロードを設計する必要があります。 特定可能な場合は、設計上のリスクを避けるようにします。
成長モデル。 ワークロードの使用量が今後どのように増加または減少するかを予測します。
コンプライアンスの変化。 将来的にワークロードにコンプライアンス要件が課されることが予想される場合は、事前に対策を講じます。 このアプローチにより、コンプライアンス遵守が必須になった場合でも再作業を減らすことができます。
リージョン展開。 ワークロードの複数リージョンへの将来的な展開を考慮します。 単一のリージョンに限定された設計では、複数リージョンに展開するために大幅なリファクタリングが必要になります。この変更にはコストがかかります。 ワークロード設計が、コンプライアンス要件が異なる複数の地域に対応する必要がある場合は、さらに複雑になります。 リージョン展開に関する合理的な予測を織り込んだ上で設計を行うようにします。
製品ロードマップ。 設計には、非推奨になる予定のコンポーネントを含めないでください。 同様に、現在プレビュー状態にある機能をデザインに含める場合も注意してください。 リリースされる可能性がありますが、キャンセルされる場合もあります。 プレビュー機能を使って一歩先を行くことで、非常に有利になる場合があります。 機能がリリースされ次第、ワークロードが運用環境に移行する準備が整います。 ただし、慎重なリスク分析を行った後にのみ、プレビュー機能を設計に含めるようにします。 許容されるリスク プロファイルを持つ機能のみを採用します。
クラウド設計パターンの詳細については、以下を参照してください。
- 信頼性をサポートするクラウド設計パターン
- セキュリティを強化するクラウド設計パターン
- コスト最適化をサポートするクラウド設計パターン
- オペレーショナル エクセレンスをサポートするクラウド設計パターン
- パフォーマンス効率をサポートするクラウド設計パターン
サポート性を高める設計
次の 3 つの主要なサポートの観点からワークロードを設計します。
クラウド プロバイダーのサポート。 ワークロードは、プラットフォームのサポート チャネルを使用する際に中断が発生しないよう、クラウド プロバイダーがサポートする構成内で動作させる必要があります。
運用状況の可視性。 インシデント対応中の混乱を防ぐため、ワークロードの運用チームが実行状態を把握できるような設計である必要があります。
カスタマー サポート機能。 設計は、ユーザーのニーズを満たすだけでなく、カスタマー サポート機能も容易にする必要があります。 サポート チームの調査や顧客支援の能力を妨げるような設計では不適切です。
スキルの維持と強化
アーキテクトの専門知識は、多くの場合、実用的な経験に根ざしています。 進化するクラウド エコシステムに対応できるよう、スキル セットの拡大に投資することが重要です。
教育。 テクノロジ プロバイダーがアーキテクトに提供するトレーニングや認定資格などの機会を探しましょう。
コミュニティ参加。 オンラインや地域のアーキテクチャ コミュニティを通じて、仲間と交流しましょう。
探索的演習。 組織が主催するハッカソンや同様のイベントに参加して、不慣れな分野のスキルを磨きましょう。
成功に向けたコラボレーション
アーキテクトは、クラウド プロバイダーや実装パートナーの専門知識を活用する必要があります。 ほとんどのプロバイダーは、ワークロードが自社のプラットフォームで成功することを望んでいます。また、アーキテクチャ設計のレビュー セッションや、自社のクラウド ソリューション アーキテクトとのコンサルティング セッションなどのサービスを提供していることも多くあります。 ベンダー関係の中から、レビューや支援を得る機会を探しましょう。
体系的な設計を心がける
アーキテクチャ フレームワークは、ワークロードのパースペクティブや方法論的アプローチを提供することでアーキテクトを支援しています。 Well-Architected Framework は、ワークロードに対する包括的な視点を提供します。 アーキテクトは、Well-Architected フレームワークを、Open Group Architecture Framework (TOGAF) などの他のアーキテクチャ フレームワークと組み合わせることができます。
アーキテクチャ フレームワークの原則、チェックリスト、アセスメント、参考資料を使用して、ワークロードに適合するプロセスを確立しましょう。 フレームワークを、マインド マッピングなどの個人的な技術と組み合わせます。
アーキテクチャにおいて、コミュニケーションは最終製品と同じくらい重要です。 確立されたプロセスにおいて、意図的な意思決定やトレードオフの認識、明確なコミュニケーションが最適化されていることを確認しましょう。