アーキテクチャのクラウドへの移行をシンプルにする7つのステップ

良い点は、ほとんどの企業がそうであるように、これまでに何度も経験したことがあるということです。およそ3年から5年ごとに、コア アーキテクチャを刷新しています。また、アプリケーションの提供方法を調整し、パフォーマンスの向上、セキュリティの強化、コストの削減にも取り組んでいます。

悪い点は、クラウドでは状況がさらに複雑になるということです。サービスをコントロールできないかもしれません。ハード コードで接続したり、昔ながらのやり方ではできないかもしれません。多少の痛みを伴うでしょう。しかし、「痛みなくして得るものなし」という言葉があります。ユーザーの行動、接続性、適切な帯域幅などを計画しなければなりません。

移行を少しでもスムーズにするために、7つの重要なステップをまとめました。

1. 既にあるものを評価する

アプリケーションの状態はどうですか？どれくらいの数がありますか？お客様のビジネスにとってどのくらい重要ですか？どのような種類のデータを保持していますか？そして最も重要なことは、それらの間の依存関係はどのようになっていますか？

アプリケーションの方向性について、どのようなカテゴリにするか考えてみましょう。4つの選択肢があります。

1. SaaSを採用する
2. クラウドに移行する
3. ハイブリッド環境を導入する
4. 現状を維持する

2. どのアプリケーションがSaaSへのアウトソーシングに適しているかを判断する

簡単なことから始めましょう。貴社のポートフォリオの中で、仮想商品であるアプリケーションを特定してください。その数はかなりのものになるでしょう。自前のExchangeサーバー、旧式の人事システム、自社製作の営業自動化ツールをサポートする必要は本当にあるのでしょうか？チームの労力や発生するOpExに見合うものでしょうか？もし見合うものでなければ、販売、人事、生産性などの適切なソリューションに加入することで、多くの手間を省くことができます。手間がかかる作業は第三者に任せましょう。SaaSを導入いただければ、すぐに効果を実感いただけます。

3. 残りの部分について分析し、決定する

次に、残りのアプリケーションを評価し、クラウドに移行するもの、クラウド用にリファクタリングするもの、そのままにしておくものを決めなければなりません。

次のような点について自問してみてください。

- アプリケーションXを移行した場合、どれだけのものが破損しますか？
- データ ストアはどこにありますか？
- 依存関係はどのようになっていますか？
- 使用しているネットワーク サービスは何ですか？
- 動作させるために通常の手順やプロトコルへの回避策が必要なアプリケーションはどれですか？

多くのアプリケーションについては、これらの質問に答えることができるかと思います。他のアプリケーションについては、実際に移動してみないと答えがわからないかもしれません。破損のリスクが大きいほど、また、依存関係が複雑であまり把握できていないほど、アプリケーションをそのままにしておく可能性が高くなります。

これらの依存関係をマッピングする際は、それらを文書化します。これは、一部のアプリケーションのみをクラウドに移行する場合にも有効です。

4. 標準化する

アプリケーション デリバリ ポリシーを検証し、標準化と自動化の機会を探ります。アプリケーションごとに手間をかけて構成を調整するのではなく、10個程度の標準的なロード バランシング ポリシーを用意しておくとよいでしょう。標準化されたストレージ階層を決定します。標準化されたネットワーク サービスを定義します。開発者に標準化のメリットを説明し、協力を求めます。開発者が迅速かつ容易に導入できるようにテンプレートを作成します。

5. アクセスをシンプルにして保護する

誰がどこから各アプリケーションにアクセスするのかを考えてみましょう。ユーザーの行動、接続性、適切な帯域幅を考慮して計画を立てる必要があります。プライベートかパブリックかを問わず、クラウドに移行しようとしているアプリケーションの多くは、どこからでもより簡単にアクセスできる必要があるかもしれません。それらをクラウドに移行することで、インフラへストラクチャの負荷が軽減されます。

また、認証やセキュリティの問題もあります。多くの企業ではこれまではアクセスの判断にアプリケーションではなくネットワークを使用していました。パブリック クラウドでは、これまでになかった新しいIDとアクセスの管理に関するテクノロジーを導入する必要があるかもしれません。

6. アーキテクチャを計画する

クラウドに移行する際には、構成要素が固定されていないため、アーキテクチャが異なります。データベースのようなモノリシックなアプリケーションでは、以前は特定のIPアドレスや他の一定の構成要素に依存していたメカニズムがクラウドでは機能しなくなります。常に変化する環境で一貫性を保つために、ロード バランサーやプロキシを追加する必要があるかもしれません。誰もが中断することなく一貫してアプリケーションにアクセスできるようにするために、制御点を追加します。

7. 容易ではないことをお忘れなく

これは難しい作業です。最初に述べたように、ITアーキテクチャは複雑です。

簡単ではないかもしれませんが、コスト削減（OpExとCapEx）やスケーラビリティだけでも価値があります。企業によっては、クラウドへの対応だけで大幅なコスト削減を実現しているところもあります。既存のアプリケーションの評価、依存関係の分析、あらゆるものの文書化、可能な限りの標準化と簡略化を行うことで、何をどのように移行するかを決定するために最適な状態にすることができます。