アプリケーションの使用時に、このアプリケーションをクラウドに移行すべきかどうかとの質問が挙げられます。 パブリッククラウドやプライベートクラウドを使用することで、既存のアプリケーションの柔軟性やパフォーマンスが向上されて保守性が簡素化されるため、新たな用途が生まれます。ただし、このようなリフト&シフトの移行には、トレードオフがあります。

アプリケーションは移行すべきでしょうか?アプリケーションを移行する場合には、この機会を利用して途中でアプリケーションに変更を加えるべきでしょうか?どのように計画を立て、実行するのですか?この記事では、上記のような疑問に回答していきます。

アプリケーションをクラウドに移行すべきでしょうか?

最初のステップとして、現在のデプロイメントで不満な部分を書き留めておきます。アプリケーションを実行しているハードウェアは、古くて管理が困難ですか?これまでよりも制御された環境にアプリケーションをデプロイすることで、アプリケーションのセキュリティを強化できますか?データセンターのフットプリントを減らしたいとお考えですか?現在の欠点をリストアップして、チームが正しい判断を下すことができます。

お使いのアプリケーションの今後について考えてみましょう。1年後にはどうなっているでしょうか?3 年後はどうでしょうか?この期間中にアプリケーションを別の場所に移行することに意味はありますか?クラウドでは、今後も使用し続けられるようなデプロイメントにすることは可能ですが、1 年後にアプリケーション自体に価値を見いだせない場合には、アプリケーションの使用を終了することが最適な選択肢かもしれません。

よくある誤解として、クラウドを使用するといつでもアプリケーションを安価にホストできるというものが挙げられます。多くの場合、従来のデータセンターよりもスケーラビリティと柔軟性が高くなりますが、コストがかかります。従来のデータセンターでアプリケーションをホスティングする場合と比較すると、このコストをコントロールできます。

API 駆動の自動化では、ネットワーク、仮想マシン、およびストレージを瞬時にスケーリングします。そのため、最初は請求額が高くなる可能性がありますが、各アプリケーションのニーズに合わせて、パフォーマンスまたはコストを最適化することも可能になります。クラウドでのユーティリティコストの体制では、「従量課金制」のメリットを活用し、需要が高いときにはスケールアップして支払う料金を増やし、その後に元の状態にスケールダウンできます。「ベースを所有してピーク時には借りる」という言葉をよく耳にしますが、これは基本的なレベルのインフラストラクチャを稼働させておき、需要の高い時期にはスケールアップできるようにしておくという意味です。

Red Hat Enterprise Linux (RHEL) も合わせてクラウドに移行し、データセンターと同じように、RHEL のコンテンツ、アップデート、サポートをご利用いただけます。

クラウドに移行するにあたり、アプリケーションに変更を加える必要がありますか?

もちろんです。簡単に言うと、クラウドをアプリケーションに適合させるのではなく、アプリケーションをクラウドに適合させる方法を見つけることができれば、クラウドへのデプロイメントでコストを抑えることができます。このようにデプロイメントをカスタマイズして、最も高い効率が得られます。

Gene Kim 氏は「The Phoenix Project」の中で、「ボトルネック以外の場所での改善は幻想である」と書いています。 移行は、技術的な負担を軽減してアプリケーションの低速部分のスピードをアップし、アプリケーションの管理を容易にする機会となります。

移行を適切に行うには、特定のアプリケーションの機能と制約、および移行先のクラウドを把握しておく必要があります。データセンターの物理サーバーを、クラウド上の大きな仮想マシンに移行するだけでは、現在抱えている問題と同じ問題が発生します (ただ場所が違うだけです)。

クラウドは、仮想マシン、ネットワーク、ストレージなどの通常のインフラストラクチャで構成されます。また、多くのクラウドでは、オペレーションチームの負荷を軽減する追加サービスを提供します。オペレーションチームは、管理対象データベースサービスなど、管理対象サービスを活用して、複雑なデータベースサーバーを維持管理するのではなく、アプリケーションと、ビジネスクリティカルなデータに集中できます。

また、ネットワークは、注目レベルが最も低いにも関わらず、最も大きな問題を引き起こす可能性がある分野となっています。アプリケーションのネットワークの設定には、時間を十分にとって計画し、セキュリティの強化を図るとともに、高額請求を回避するようにしてください。クラウドの多くは、ネットワーク上での厳密かつ細かいセキュリティ管理が可能です。このようなセキュリティ機能を利用して、重要なインフラストラクチャへのアクセスを制限できます。 

セキュリティ対策として、できるだけインスタンス間にはプライベートネットワークするようにし、同時にパブリックネットワーク上のインスタンス間で通信をする場合には高額請求が発生しないように注意してください。クラウドデプロイメントにおいて、ネットワーク使用料が最大コストの 1 つとなります。

移行の計画はどうすればよいですか?

初めてクラウドにデプロイするときは、まるでお菓子屋さんに入ったような気分になります。記憶に残るネーミングと一見手頃な価格で、価値のあるサービスが数多く用意されていますが、気をつけてください。クラウドには膨大な選択肢があり、誰もがそのオプションに惹かれますが、それが原因でデプロイメントが困難かつ高額になる可能性があります。

予算にソフト制限とハード制限をもたせることで、適切なサービスを自由に選択できますが、過剰な支出が余儀なくされます。スケーリングの簡素化や、影響の大きいエリアのパフォーマンス向上に、コストをかけることを検討してください。たとえば、アプリケーションのストレージ I/O は多用するが、メモリーはあまり使用しない場合には、仮想マシンのサイズを縮小して、ストレージパフォーマンスをスケールアップできるように、高速なストレージメディアを使用することができます。このように計画の過程で調整することで、デプロイメントの適切な開始地点に立ち、デプロイメントを後でスケールアップまたはスケールダウンできるようになります。

Yogi Berra 氏はかつて「どこに行くのか分からなければ、どこか他の場所に行き着くだろう。」と言いました。 

移行する前に、最初から最後までの計画を作成します。計画に以下が含まれていることを確認します。

  • さまざまな手順間の依存関係
  • すべてが軌道に乗っていることを確認するための Go/No-Go チェックポイント
  • ステークホルダーとステータスを共有するためのコミュニケーションガイドライン
  • 移行後のデプロイメント変更に対する変更管理

全員が同意した後には計画に従うようにします。進捗や、次回の移行で変更すべき点を文書にまとめます。この手順は多少面倒ではありますが、この手順を踏むことで移行の省力化、簡素化かつ効率化が可能になります。

まとめ

柔軟性およびスケーラビリティの高いインフラストラクチャと、詳細にわたるセキュリティ管理を活用できるアプリケーションのクラウド移行を検討します。移行は、アプリケーションの運用上の課題を分析し、改善する機会となります。 

クラウドはコストが高くなりがちですが、通常、運用負荷を軽減するサービスが豊富にあります。クラウドサービスの数の多さに圧倒されることもありますが、協力体制と良好なコミュニケーションでしっかりとした計画を立てることで、最良の結果を得ることができます。


About the author

Major Hayden is a Principal Software Engineer at Red Hat with a focus on making it easier to deploy Red Hat Enterprise Linux wherever a customer needs it. He is also an amateur radio operator (W5WUT), and he maintains a technical blog at major.io.

Read full bio