『V1 AWS設計（AWS移行時の初期設計）』のための効果的な意思決定

自組織の既存のビジネスアプリケーション・ポートフォリオを確認して、『V1 AWS設計』すなわち、AWSへ移行するための最初のアーキテクチャ設計を作成する場合、しばしば進捗を阻む以下の2つの主要な事象への対処を検討しなければなりません。

1. 技術チームは、モダナイゼーションとマイグレーションのバランスが取れた明確なパスを見つける必要があります。
2. プラットフォームを変革するための明確な基準を提供するとともに、既存のシステム上でも新しいビジネス・ケイパビリティ（機能のリリースなど）を提供し続ける必要があります。

クラウド化の流れを加速してV1 AWS設計を実装するには、確立された効率的な意思決定プロセスを持つことが極めて重要であることが分かってきました。このプロセスを成功させるには、スピードのバランスを取り、モダナイゼーションの足かせとなる技術的負債に対処し、優先度の低い最適化はシステムをAWS上に配置した後まで延期するアプローチが有効と言えます。

このブログでは、AWSへの初期移行（V1）の明確なパスの決定方法、アプリケーションとインフラのアーキテクチャおよび構成をどの程度変革するか、そしてアプリケーションをAWSに移行する際の段階的なデプロイ自動化の程度に関して、効果的な決定を行う方法を紹介します。

V1 AWS設計の戦略

アプリケーションをクラウドに移行するための7つの一般的な移行戦略（「7R」）に加えて、以下の追加の戦略もV1アーキテクチャを作成するときに役立ちます：

1. まず移行する。その後、最適化する。従来型の「リフト&シフト」によって素早くクラウドへ移行し、まずは目に見えるランニングコスト削減を実現した後、クラウド上での最適化を進めます。設計レビューを行いながら、長期的に考えてモダナイゼーションやリファクタリングすべきアプリケーションを特定します。そして、それらをAWS移行後に対応すべきバックログとして記録しておきます。場合によっては、3〜5年で利用終了する予定のシステムは、AWSリージョンに隣接するコロケーション施設へ移行することが効果的なケースがあります。これは、他への依存性のあるワークロードであっても、依存性の問題を解決するためにシステムを書き換えることなく、クラウドへ移行することが可能であることを意味しています。
2. 重要なものをモダナイズする。優先順位とリソースが一致している場合は、ビジネス価値、技術的負債、およびその他の優先順位に応じて、段階的または完全なモダナイゼーションに投資します。技術的負債の程度が高いシステムや、メインフレームおよびミッドレンジシステムを含むレガシーワークロードへの構造的な依存を解決するチャンスがあるかを評価することから始めます。ビジネスニーズに基づいて、レガシーワークロードをリタイア、リパーチェス、リテイン、またはリファクタリングします。
3. 最小限の最適化。素早さを妨げる種々の問題に対処するため、すべてのスタックに渡って陳腐化したテクノロジーをアップグレードもしくは一新します。加えて、新機能の開発をスローダウンさせたり、要員を差別化されない重労働へ誘引したりする課題への対処のため、レガシーシステムを切り離します。ほとんどの場合、これを行うにはAWSに移行する前に、どこまでモダナイズするかを決定するための、アプリケーションチーム、テストチーム、およびビジネスプロダクトのオーナーとの緊密な調整も必要です。

アプリケーションポートフォリオ全体でこれらの3つの戦略に従うことで、あなたの組織のクラウドトランスフォーメーションで図1に示すフライホイールを実現することができます。図1. クラウドトランスフォーメーションのフライホイール

V1 AWS設計の仕様

アプリケーションとインフラストラクチャのアーキテクチャおよび構成をどれだけ変革するか、また、段階的なデプロイ自動化をどの程度進めるかといった設計上の決定は、V1 AWS設計の中で明らかにされます。トレードオフの評価を行なって、オペレーティングシステム（OS）、データベース、アプリケーションコード、高可用性アーキテクチャ、デプロイ自動化、およびサービスアーキテクチャの機能強化といった要素のうち、どれを実装すべきか判断するでしょう。また、移行後にAWS上で最適化するものとして、バックログに入れて延期するサービスを見極める必要もあります。

単純な「リフト&シフト」と完全なクラウドネイティブ化によるモダナイゼーションの間に、チームが実装可能な様々なV1設計の改善オプションがあります：

• EOL(End-Of-Life)済み、もしくは近くEOLを迎える予定のものをアップグレードする。古いバージョンのOSやミドルウェア、およびアプリケーションコンポーネントはセキュリティリスクに晒される可能性があります。
• Infrastructure as Code (IaC)を適用する。AWS Service Catalogから利用できるテンプレート、クイックスタート、セキュアなスタックを使用して、インフラストラクチャのプロビジョニングを自動化します。
• 自動デプロイを段階的に導入する。コントロールが組み込まれた一般的なクラウドベースのコードパイプラインを使用して、ミドルウェアとアプリケーションコードの自動デプロイを進め、DevSecOpsプラクティスまたはブルー/グリーンデプロイメントを採用します。
• AWS Auto Scalingを使用する。水平スケーリング、インスタンス入れ替え、およびオートヒーリング/オートリカバリメカニズムを許可して、手動操作タスクを自動化します。
• レジリエンシー（障害からの回復力）の向上。 レジリエンシーまたは災対要件のある基幹業務アプリケーションのため、他のアベイラビリティゾーンやリージョンへの再配置もしくはフェイルオーバーを有効化します。
• データセキュリティと保護の強化。ライフサイクル全体に渡り、機微データを保護します。たとえば、保護対象保健情報をフィールドレベルで暗号化します。
• Amazon Elastic Compute Cloud (Amazon EC2)よりもマネージドサービスへ移行する。マネージドサービスの一種であるAmazon Relational Database Service (Amazon RDS)のようなマネージドデータベースを利用すると、インフラ担当者の差別化されない重労働が削減されます。
• コンテナへ移行する。モノリス（密結合したアプリケーション）を小さなサービスに分割し、管理とデプロイを容易にするためアプリケーションをコンテナ化します。既存のDockerイメージがすぐに利用可能なコンポーネントから始めます。
• 機会を見つけてリファクタリングを実施する。アプリケーションスタックの特定の部分をリライトします。たとえば、イベント駆動型コンポーネントをサーバーレス（AWS Lambda, AWS Step Functions, AWS Batchなど）に移行します。または、プロプライエタリなデータベースエンジンをAWSのデータストア（Amazon Auroraなど）に移行します。
• アプリケーションレイヤーを標準化する。アプリケーションスタックとアーキテクチャを標準化します。たとえば、最小限のリファクタリングで十分なWeb /アプリケーション/ミドルウェアレイヤーのテクノロジーを統合します（Apache Tomcat共有レイヤーへの移行など）。
• リパーチェスの実施。たとえば、Software as a service(SaaS)へ移行したり、代替機能をクラウドベースの市販の既製品のアプリケーションとしてAWSマーケットプレイスから購入します。

AWSにデプロイするときは、これらの改善を考慮してください。重要な変更は、移行前に実装する必要があります。 それほど重要ではない変更は、AWSへの移行が完了した後に対処するものとして、最適化バックログに含めることができます。

これらの改善を達成するための時間と労力は、それらがビジネスニーズ、利用可能なスキル、およびリソースとどのように整合しているかを評価する必要があります。次に、V1 AWSの設計改善に投資する他の機会を評価できます。継続的な改善の考え方を使用して、バックログ項目を将来のスプリント目標に含めることができます。

V1 AWS設計を実装する上での2つの考慮事項

スピードは完璧に勝る。最も重要なのは、関連するすべての利害関係者を巻き込んでV1 AWSの設計上の決定を迅速に行うことです。次に、合意された計画を実装し、残りの最適化の機会はAWS移行後のバックログに延期します。 AWSへのカットオーバーは「双方向の扉（two-way door）」です。これは、V1 AWSの設計を仔細に考え悩む必要がないことを意味します。 AWS上で調整（必要に応じてサイズを大きくする）したり、元に戻して再試行するのは容易です。

パターンベースの設計アプローチ。お客様への対応の中で、我々は、お客様のワークロードの80％以上が、各種のアプリケーションタイプをサポートする最大10から15の再利用可能なV1 AWS設計アーキテクチャパターンに収まることに気づきました。これらのパターンが設計され承認されたら、チームにそれらを実行させます。チームは必要に応じて調整およびカスタマイズできますが、対象分野の専門家（Subject Matter Expert, SME）およびリードクラウドアーキテクトは、構築チームが作業を開始する前に増分の変更を確認します。

まとめ

このブログでは、移行を加速し新機能の市場投入までの時間を短縮するための、効果的な意思決定を行う方法をご紹介しました。
明確な目標とビジネスオーナーシップがなければ、チームは意思決定の停滞に苦しみます。チームは何もできず、システムをオンプレミスのままにしたり、そのまま移行したり、完全なリファクタリングを行ったりします。明確なV1設計プロセスと意思決定の明確なオーナーシップを持つことは、利害関係者に力を与えます。これは、最初の一歩を踏み出し、迅速に行動するために重要です。 チームがこれらの決定を下し、迅速に行動し、実験し、失敗を恐れないように権限を与えることをお勧めします。

参考文献

会社のクラウドトランスフォーメーションを拡大し、加速するためのさらなるガイダンスが、こちらのホワイトペーパーに記載されています：Cloud-Driven Enterprise Transformation on AWS.

	Rostislav Markov Rostislav Markovは、AWS Professional Servicesのプリンシパルアーキテクトです。 グローバルデリバリーチームの移行リーダーとしてグローバルで戦略的な顧客やパートナーと協力して、最大のトランスフォーメーションプログラムに取り組んでいます。 仕事以外では、彼は家族と屋外で過ごしたり、ニューヨーク市の文化を探索したりすることを楽しんでいます。
	Andrew Haggard Andrew Haggardは、大規模移行、コールセンターの変革、AI / MLの適用により、顧客がエンタープライズクラウドビジネストランスフォーメーションを加速し、顧客を喜ばせるのを支援しています。 仕事以外では、Andrewは水上飛行機の飛行、料理、そして２匹の反抗的だが愛らしいパグ犬に基本的なしつけを行うことを楽しんでいます。
	Nirav Kothari Nirav Kothariは、AWS Professional Servicesのプリンシパルコンサルタントです。 この役割において、Niravは、クラウドの採用、大規模移行、トランスフォーメーション、セキュリティ、基盤アーキテクチャ、自動化など、AWSへの移行を成功させるために必要な戦略的イニシアチブで、いくつかのFortune 500企業と大企業のお客様を支援してきました。

この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルはこちら）