ハイレベルな戦略
組織がクラウドに移行する準備ができていると判断したら、コンテキストに応じた決定を行う必要があります。 一般的な指針となる戦略を持つことが重要です。
クラウド移行戦略を通じて対処したい目標と問題を明確にすることで、ビジネス戦略とテクノロジ戦略を確実に一致させることができます。 何を達成したいですか?
- コストを削減したり、市場投入までの時間を短縮したりしようとしていますか?
- 熟練したスタッフを惹きつけ、維持するのに苦労していませんか?
- 製品やサービスの品質を向上させようとしていますか?
- これらの目標は緊急ですか、それとも長期的なものですか?
- クラウドに移行する際に満たす必要のあるコンプライアンス要件はありますか?
これらの要因は、クラウド移行戦略がどのようなものであるべきかを決定する上で重要です。
ベンダーの選択
ワークロード要件が同種の比較的小規模な組織の場合、技術的な冗長性やベンダーロックインの回避のために複数のクラウドベンダーに投資する必要がほとんどないため、単一ベンダーのクラウド戦略が最も適している可能性があります。
多様なワークロードとさまざまなレベルの技術要件を持つグローバル銀行など、はるかに大規模な組織では、各プロジェクトチームが要件に最も適したベンダーを柔軟に選択できるため、マルチクラウド戦略を追求する可能性が高くなります。 さらに、大規模な組織では、内部および外部のコンプライアンス要件を満たす必要がある可能性が高く、比較的短期間でクラウド ベンダー間でワークロードを移動する機能が必要になる場合があります。
従来のデータセンターとクラウドベンダーの両方が関与するハイブリッド戦略は、特にクラウドへの移行が数年に及ぶ場合、中規模から大規模の企業にとっても理にかなっている可能性があります。 この戦略は、ビジネス内でのクラウド テクノロジの実装についてさらに学習するにつれて、クラウド移行戦術をより動的に進化させる必要がある場合にも関連している可能性があります。
6つのR
クラウド移行の目標とベンダー戦略を決定したら、次のステップは、ワークロードをクラウドに移行する方法を決定することです。
まず、既存のアプリケーションの監査を実施します。 これにより、クラウドへの移行に必要な作業のレベルと性質を把握できます。 この監査では、クラウド移行を担当するチームに採用してもらいたいアプローチに基づいてアプリケーションを分類できます。 AWS は、6 つの「一般的な移行戦略」を概説しています。 これらは全面的に適用することも、組織の規模や複雑さに応じて、各チームがその時点での特定のセットアップに最も適した戦略を選択することもできます。
1.リホスト
最初の最も簡単な戦略は、アプリケーションを再ホストすることです ("リフト アンド シフト" とも呼ばれます)。 これには、データセンターで稼働している物理サーバーから、クラウドで稼働している仮想サーバーへの移行が含まれます。 一般に、これにはコードの変更は必要なく、プロセスやネットワークなどの周辺テクノロジへの変更も比較的少なくて済みます。 また、組織は、他のクラウドネイティブ プラクティスに必要なクラウドのスキルと経験を身に付けることができます。
2. リプラットフォーム
このアプローチは「リフト、ティンカー、シフト」とも呼ばれ、リホスティングと似ていますが、アプリケーションレベルで多くの基本的なクラウドサービスを統合することで、さらに一歩進んでいます。 たとえば、AWS IAM(Identity and Access Management)をアプリケーションに統合して、従来のデータセンター指向のIAMシステムを置き換えたり、補完したりすることができます。
3. 買戻し
このアプローチは「ドロップ&ショップ」とも呼ばれ、既存のオンプレミスアプリケーションをライセンスされたクラウドベースのサービスに置き換えます。 これには、ビジネスで使用するライセンスモデルの変更、メンテナンスコストの削減、アップグレードへの迅速かつ簡単なパスの許可が含まれる場合があります。
4. リファクタリング/リアーキテクト
よりクラウドネイティブなアプローチは、既存のコードベースを、より最新のクラウドサービス内で機能するように変更または拡張することです。 1 つの例は、アプリケーション コードをコンテナー化し、構成を実行して、Amazon の EKS や Azure の AKS などのクラウドベースの Kubernetes サービス内で実行することです。 これには、既存のコードベースを機能させ、スケーラビリティを向上させるために、大幅な書き換えが必要になる場合があります。真のクラウドネイティブツール(AWS LambdaやAzure Functionsなどのサーバーレスツールなど)を使用するために、完全な書き直しが必要になる場合もあります。
5. 引退
最後の 2 つの "パッシブ" 戦略では、ワークロードはクラウドにまったく移行されません。 ワークロード監査により、冗長なシステムや保守する価値がなくなったシステムが明らかになる場合があります。 これらのアプリケーションは廃止できます。
6.保持
最後の「パッシブ」戦略であるリテンションでは、アプリケーションの実行を継続し、当面の間はクラウドに移行しないことを選択します。 アプリケーションをクラウドの外部に保持する理由はいくつか考えられます。
- アプリケーションを実行できる場所に関する規制上の制約、またはセキュリティに対する社内の高いコンプライアンス要件
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- アプリケーションの移動によって引き起こされる中断のビジネス・ケースがない
- レガシーシステムはクラウド環境でサポートされない
どこから始めるか
全体的な戦略を決定し、ワークロードごとに戦術的なアプローチを分類することに加えて、ワークロードの移動をサポートするクラウド インフラストラクチャを構築する方法を計画する必要があります。 1 つのアプローチは、クラウドで独自のシステムを構築する方法を各チームに選択させることです。 ただし、このアプローチには、チームが実装のアンチパターンを複製し、互いの間違いを繰り返したり、内部/外部 のコンプライアンスルールに違反したりする可能性があるため、いくつかの欠点があります。
別のアプローチは、一種の集中型「センターオブエクセレンス」またはクラウドインフラストラクチャチームを作成することです。 このチームは、他のチームがワークロードを実行できるコア システムを配置することを選択できます。
これらのガードレールの確立に関しては、他のものよりも優先すべき特定の設計要素があります。
アカウント
クラウドアーキテクチャの最も基本的な単位は、クラウドアカウントです。 組織全体で 1 つのアカウントを使用すると、ほとんどの場合、アカウントの制限にぶつかるため、スケーリングに失敗します。 したがって、アカウントの境界を決定することが重要です。 アカウントは、特定の部署、個々のチーム、またはソフトウェア サービスのグループを表すために使用されますか? これは財務部門でどのように機能しますか? 請求書は誰が受け取るべきですか? コストがすぐに積み重なる可能性があるため、これを早期に把握することが重要です。
ファイアウォール
アーキテクチャの次に基本的な単位は、 ID およびアクセス管理システム です。 クラウドインフラストラクチャが成長するにつれて、さまざまなクラウドサービスやデータへのユーザーアクセスのセキュリティへの影響を考慮する必要があり、早ければ早いほど良いです。 これらのルールを、既に実行されているシステムに遡及的に適用することは、複雑になる可能性があります。
ネットワーキング
クラウドへの移行には、既存のネットワークの仮想化または完全な再設計のいずれかが含まれます。 VPC (AWS) または VNet (Azure) サービスを使用すると、分離されたネットワークを設定して、アカウント内で個別のサービスセットを実行できます。 組織のサービスと IP アドレスなどの基本的なネットワーク リソースとの間の ネットワーク間通信 については、慎重に検討する必要があります。
データ移行
コンピューティング サービスをクラウドに移行するのは簡単ですが、データの移行は少し難しい場合があります。 主要なデータ ストアは、移動に慎重な計画を必要とする大規模で複雑なインフラストラクチャである可能性があります。 これには、組織のパフォーマンス、コンプライアンス、運用性の基準に準拠しながら、データをクラウドに移行する方法を十分に深く理解する必要があります。
結論
大まかなクラウド戦略が明確になったら、 クラウド移行 戦略を成功させるには、ビジネスのあらゆる側面について綿密な計画と検討が必要です。 次のステップは、単純な単一ベンダーの移行、マルチクラウドベンダーのアプローチ、ハイブリッド戦略など、適切なクラウドベンダー戦略を選択することです。 最後に、アプリケーションのオンボードを開始する前に、まず主要なインフラストラクチャ コンポーネントを検討して、クラウド移行を設計する必要があります。
このブログ記事が興味深く、価値のあるものであったことを願っています。
コンテナ/Kubernetesとサーバーレスサービスに関する今後のブログ投稿にご期待ください。
クラウドへの移行を始めようとしている方は、 安全なクラウド移行のための 5 つのベスト プラクティスに関する新しいホワイト ペーパーをお読みください。
チェック・ポイントのクラウドセキュリティ・ソリューションの詳細については 、こちら をご覧いただくか、 こちらからチェック・ポイントのクラウドセキュリティ・エンジニアによるデモをご予約ください。
安全なクラウドアーキテクチャの設計と実装の方法については、 こちらのホワイトペーパーをご覧ください。
Feedback