「準備を怠ると、失敗する準備をすることになる！」ということわざを聞いたことがあると思いますが、このブログでは、大規模なクラウド移行に備えることについて見ていきます。
ワークロードをAWSに移行する際に、成功する災害復旧計画を構築するために考慮すべき特定の必要な戦略があります。
Amazon Web Services（AWS）のUS SMB GreenfieldのパートナーソリューションアーキテクトであるHarshil Shah氏に、最新の「Talking Out Cloud」でこのトピックに関する彼の洞察を共有してもらいました。
AWSテクノロジーがクラウド上での大規模なアプリケーション開発とデプロイメントをどのように効率化できるかという彼の好奇心に駆られたHarshil氏は、実りあるAWS移行につながる基本的なアプローチについて語りました。
＃1 ワークロードをAWSに移行しようとしているお客様にとって、基盤となる技術レビューの目的は何ですか？
AWS Foundational Technical Review（FTR）は、お客様がAWSクラウドでワークロードを設計するためのベストプラクティスに基づいてワークロードが構築されていることを確認できるようにすることを目的としています。セキュリティ、運用効率、および信頼性に対してこれらのワークロードを検証するのに役立ちます。
これにより、お客様はAWSソリューションアーキテクトと協力して、RTOおよびRPO要件を定義するのに役立つ事業継続計画を策定できます。お客様は、データ損失からワークロードを保護し、中断が発生した場合にシステムを復元するために、さまざまな災害復旧戦略から選択できます。
FTRは、オンプレミスインフラストラクチャからクラウドに移行する場合でも、異なるクラウドプロバイダーからAWSクラウドに移行する場合でも、全体的な移行戦略にも役立ちます。FTRを完了すると、AWS Marketplaceを通じてSaaS製品としてサービスを提供できるようにお客様をサポートします。
＃2 災害復旧計画が実施されていない場合、潜在的な影響は何ですか？
災害復旧計画は、一般に事業継続計画と呼ばれ、ビジネスが円滑に運営されるために不可欠です。災害はまれですが、非常に予測不可能であり、見過ごされると、ビジネスの全体的な機能に壊滅的な影響を与える可能性があります。
災害復旧戦略がない場合の潜在的な影響には、データの完全な損失、ビジネスの中断、顧客の損失、収益の損失、計画外のダウンタイムによる評判の低下、そして最終的にはビジネス全体の失敗が含まれます。時間内に修正されない場合、ITインフラストラクチャに重大な損害が発生する可能性があることをご理解いただけると思います。
対照的に、適切に定義された災害復旧計画は、データが保存および処理されるITインフラストラクチャ全体が、予測不可能な障害または停止が発生した場合に回復できることを保証するのに役立ちます。自然災害またはその他の人的エラーによる災害の結果として、地理的に離れた場所にデータを複製し、既存の地域の障害が発生した場合に利用可能な地域にユーザートラフィックをルーティングするのに役立ちます。
＃3 AWSコンサルティングパートナーは、いつその会話またはプロセスに参加しますか？
AWSパートナーは、お客様が災害復旧計画を構築およびテストするのを支援し、利用可能な場合はマネージドサービスオファリングを活用することを選択する上で非常に重要です。
AWSはまた、お客様が事業継続計画を定義し、目標復旧時間（RTO）および目標復旧時点（RPO）を満たすのに役立つ規範的なガイダンスを提供するホワイトペーパー、ワークショップ、ブログを通じて、大量のリソースを提供しています 目標。[RTOとは、障害が発生した場合にシステムが復旧するまでにかかる時間であり、RPOはシステムがデータ損失をどれだけ抑制できるかを定義します。]
さらに、AWSは、パートナーが障害発生時にお客様の環境をバックアップおよび復元するのに役立つツールとサービスを提供しています。定義されたRTO/RPO要件に応じて、AWSパートナーは、以下に基づいてお客様の災害復旧戦略を実装できます。
- バックアップと復元を選択するか、パイロットのような戦略を選択できます。
- 彼らは、彼らが持っている要件に応じて、アクティブ、アクティブな種類のセットアップを持っているウォームスタンバイを選ぶこともできますが、災害が発生した場合にのみ、他の地域をスピンオーバーします。
- そして最後に、ビジネスクリティカルなワークロードまたはミッションクリティカルなワークロードの場合、両方の地域が同時に動作しているアクティブなオファリングがあります。
これらの各戦略について、AWSは、EC2、EBS、EFS、データベーススナップショットなどのインフラストラクチャコンポーネントのバックアップを異なる地域間で有効にするAWS Backupなどの関連サービスを提供しています。今日、AWSは26を超える地理的地域で事業を展開しており、これらの各地域内に5つ以上のデータセンターがあります。
これらのバックアップは、地域全体が影響を受ける場合に簡単に復元できるポイントインタイムコピーです。AWSは、ボタンをクリックするだけでインフラストラクチャをコード（IaC）として別の地域にデプロイするのに役立つサービスを提供します。SourceFuseのようなAWSコンサルティングパートナーは、エンジニアリングチームによる最小限の重労働でそのIaCを構築するのに役立ちます。
これらのテンプレートの構築はお客様にとって圧倒される可能性があるため、パートナーは、大規模なクラウド移行プロセス中に特定のワークロードのインフラストラクチャ全体を構築するアセットとしてこれらのテンプレートを提供することで支援できます。
＃4 CTOまたはCIOは、モダナイゼーション主導の移行を探す際に何を考慮する必要がありますか？
私の経験では、CTOやCIOと協力することは、プライベートクラウドまたはパブリッククラウドでの運用における現在のビジネス上の課題、独自のデータセンターでの課題、異なるドメインにわたるアプリケーションの運用における課題、またはテクノロジーまたは人材スキルに関する組織的なギャップを特定できる場合に非常に役立ちます。
そのため、現在のインフラストラクチャに関する技術的な課題と、モダナイズするためにギャップを埋めるために何が必要かという観点から、これについて話し合います。
モダナイゼーションの取り組みを開始するには、現在のアプリケーションの状態、そのアクセスパターン、そのデプロイメントサイクル、デプロイメントがどのように行われているかなどの初期発見が必要です。これらはすべて、適切なクラウド移行およびモダナイゼーション戦略を特定し、現在のIT課題を解決するための非常に重要な要素です。
モダナイゼーションは、これらのお客様がクラウドプラットフォームの利点と機能を最大限に活用し、チームが最小限の管理オーバーヘッドでアプリケーション機能をより迅速に開発できるようにするのに役立ちます。
サーバーレスコンピューティングなどのクラウドテクノロジーは、お客様がマイクロサービスベースのアーキテクチャを構築するのに役立ちます。これは、コアビジネス機能とインフラストラクチャの管理/管理の構築のみに焦点を当てるよりもさらに進んだ、より広範なモダナイゼーションの取り組みの一部です。
クラウド内で採用するテクノロジーの適切な選択は困難な場合がありますが、SourceFuseのようなAWSパートナーは、クラウドネイティブなモダナイゼーションアプローチを使用して、AWSで大規模なアプリケーションを実行するための最適なテクノロジーオプションを簡単に活用できるようにします。
SourceFuseは、AWSパートナーネットワーク内のアドバンストティアパートナーであり、AWSとのコラボレーションにおける移行、コンサルティング、DevOpsコンサルティング、インフラストラクチャおよびサポートサービスの提供資格全体で実績のある能力を備えています。さらに、SourceFuseは、クラウドに関するチームをトレーニングし、クラウドスキルを開発するための実践的な没入型ラボも提供できます。そのため、安全な場所にいます。
＃5 SourceFuseチームとの協力経験はどうでしたか？
私たちが活用するプロセスは非常に簡単でシームレスです。まず、お客様のユースケースが移行/モダナイゼーションを中心に構築されている、または重大な災害復旧要件がある機会を特定します。これらの場合、AWSアカウントチームとソリューションアーキテクトはお客様と緊密に連携し、SourceFuseを会話に組み込みます。
パートナーとの連携方法は、主要な配信要素とタイムラインを詳細に定義する作業明細書を提供することです。これは、お客様が活用する上で非常に有益であることが証明されています。プロジェクトがどのように進捗し、SourceFuseがクラウドジャーニーを通じてどのように支援するかについて、明確な全体像を把握できます。
