クラウド移行のマスタリング：成功させるためのベストプラクティス
「クラウド移行のマスタリング：成功を収めるためのベストプラクティス」
クラウド移行プロジェクトは、トップエグゼクティブが効率とコスト削減を求める中で、急速に進行しています。そして、クラウドが答えであり、みんなが進むべき方法であると言いたくなるかもしれませんが、それは完全に真実ではありません。私はエンジニアとしてのプロのキャリアを通じて、異なるシナリオを目にしてきました。中規模の企業がクラウドへの移行を決定することから、エンタープライズグレードの企業がオンプレミスインフラを選ぶことまで。そして、その道は全く簡単ではありません。
もしチームがクラウド移行の準備をしているのなら、この記事は実践的なアプローチを提供します。
クラウドか否か、あるいはクラウド移行戦略を構築する前に答えるべき3つの質問
クラウド対オンプレミスの話は、利便性対制御という観点からよく見られます。クラウドではオペレーティングシステムを選び、パッチを管理できますが、ハイパーバイザーやハードウェアパフォーマンスを本当に制御することはできません。したがって、会社がどのような道を選ぶかに関しては、ビジネスが達成しようとしている明確な理由と目的が必要です。
以下の3つの質問に答えることを提案します。これにより、クラウド移行が正しい選択であることを確認できます。
1. アプリケーションにとってリアルタイム性能はどれくらい重要ですか？
ソリューションのパフォーマンスは常に重要です。それについては議論の余地はありません。しかし、一部のネットワーク集中型のアプリケーションでは、リアルタイムのパフォーマンスがミッションクリティカルになります。レイテンシが最大の敵となる広告技術プラットフォームを考えてみてください。100ミリ秒以上の遅延は、入札や広告スペース、収益の損失につながる可能性があります。したがって、ネットワークインターフェース、コア、ドライバによって引き起こされる遅延は深刻な問題になり得ます。オンプレミスのデータセンターは、システムのコアを変更したり、必要なパッチをインストールしたり、ドライバやネットワークインターフェースを変更することで、最大のパフォーマンスを得るためにこれらの要素を本当に制御できる唯一の場所です。
2. 重いが高度に予測可能なワークロードはありますか？
さて、大規模なデータ分析、統計計算、機械学習モデルのトレーニングなど、高い計算能力を必要とするコンピュート集中型のアプリケーションを考えてみましょう。この種のソリューションでは、ハードウェアはほぼ最大容量で継続的に動作しています。そして、これらのCPU集中型アプリケーションを実行するクラウドコンピューティングのコストは非常に高額になる可能性があります。
3. 需要に季節的なスパイクはありますか？
オンプレミスのデータセンターの問題は、トラフィックの急増が発生した場合に即座にスケーリングできないことです。それを行うためには、まず新しいハードウェアを物理的に追加する必要があります。しかし、クラウドではスケーリングを瞬時に行え、ビジネスの運用に影響を与えることなく、秒単位で行うことができます。そのため、定期的に季節的な需要の急増（例：クリスマス前）を経験する場合、クラウドはその需要に対応するために必要な柔軟性と俊敏性を提供します。
クラウド移行のアプローチ方法
では、最も興味深い部分であるシステムをクラウドに移行する方法について話しましょう。Salesforceベースのアプリケーションを持っている場合、インターネット上でクラウド移行のチュートリアルを簡単に見つけることができます。ただし、Salesforceプラットフォームとカスタムビルトのソリューションで構成されるエコシステムがあり、それらが特別に設計されたETLプロセスを通じて接続されている場合、使いまわしのガイドは存在しません。したがって、オールインワンのアプローチは存在しないことを念頭に置きながら、どこから始めるべきですか？
1. ベースライン評価を実施する
論理的に考えれば、最初のステップは何に取り組んでいるかを理解することです。ソリューションがどのような技術とデータベースを使用しているか、他のシステムとコンポーネントとどのように統合されているかを把握する必要があります。
すでにクラウドはソリューションの運用環境を制御することをお話ししました。では、もしシステムが直接暗号化ボードとやり取りするか、ハードウェアIDにリンクされたライセンスを使用する場合はどうでしょう？初期段階で全体システムの運用において重要なエレメントや統合を理解することが重要です。
2. 移行の優先順位付けを行う
先述のように、単にクラウド移行するだけでは決して良いアイデアではありません。このプロジェクトによって達成したい妥当な理由と具体的な目標が必要です。同時に、予備的なベースライン評価の中で、移行の際に最も問題が発生する可能性のある箇所を明らかにしました。この2つのマッチングによって、最も重要な問題に優先順位を付けた効果的な移行計画を準備することができます。たとえば、クラウドへの移行の主な目的がスケーラビリティのボトルネックを解消することである場合、スケールが必要なシステムを最初にクラウドに移行します。
3. 依存関係をマップする
最初にクラウドに移行するものを知ったら、依存関係について理解する必要があります。例えば、アプリケーションが3つのデータベースを使用しているとします。1つのデータベースはアプリケーション専用なので、クラウドへの移行は簡単ですが、他の2つは他のシステムと共有されています。このデータベースやそれらを使用するシステムに対してどうするか、という問題が浮かびます。
さて、ここでは異なる選択肢があります。場合によっては、オンプレミスのデータセンターをクラウドにVPNを介して延長することで、共有ネットワークインフラストラクチャを設定することができます。または、データベースをAWSに移行し、ソリューションがそこからデータを簡単に取得できるようにすることもできます。ただし、大量のデータがある場合、クラウドへのデータ移行は困難な場合があります。また、システムの運用や関連するビジネスワークフローを中断することはできないため、レプリケーションインスタンスを起動して設定し、その後に移行キューを設定する必要があります。
4. 適切な戦略を選ぶ
最もシンプルなクラウド移行戦略はリフト＆シフトです。もしソリューションがサーバ上の仮想マシンにホストされている場合、VMイメージを取り、それをクラウドに転送するのが最も簡単な方法です。ただし、この戦略には大きな運用コストがかかるという注意点があります。仮想マシンを起動すると、実際に動作しているかどうかに関係なく、その運用時間全体に対して支払いを行う必要があります。
リフト＆シフトが選択肢ではない場合、システムをコンポーネントに分解することができます。例えば、データベースが仮想マシン上で実行されている場合、それをクラウドの新しい仮想マシンに移動するか、そのためのマネージドサービスを使用し、このデータベースの接続文字列を再構成することができます。その結果、データベースをクラウドに移行するだけでなく、Amazonのサービスが異なる地理的地域で実行されるため、可用性も向上します。
クラウド移行戦略のアプローチ方法のもう一つは、ソリューションがモノリスであるか、クライアントサーバーアーキテクチャにフロントエンドクライアントアプリと複数のAPIがあるかを調べることです。もしそうであれば、これらのAPIは別々の仮想マシンにホストすることができます。または、バックエンドをLambda関数にリファクタリングすることもできます。これにより、サーバーレスアーキテクチャに一歩進むことができます。
まとめ
今日の議論から明らかなように、クラウド移行は挑戦的で魅力的なトピックです。そして、各ソリューションは独自のテックスタックと依存関係を持つため、クラウド移行のための1つのガイドラインやチュートリアルは存在しません。ただし、ベストプラクティスがあります。ベースラインアセスメントを無視しないこと、ビジネスニーズに応じて移行キューを優先すること、すべての依存関係を特定し、プロジェクトに最適なロードマップを準備することです。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
