クラウド アーキテクチャの準備

アーキテクチャをクラウドに移行する作業を簡素化する 7 つのステップ。

認めましょう。ほとんどの IT アーキテクチャは複雑です。 クラウドへの移行を検討している場合、移行時にアーキテクチャと組織に必要となる大規模な変更について懸念するのは当然です。

幸いなことに、ほとんどの企業と同様、あなたもこれを以前にやったことがあるはずです。 何回も。 約 3 ~ 5 年ごとにコア アーキテクチャを全面的に見直します。 アプリケーションの配信方法を調整します。 パフォーマンスの向上、セキュリティの強化、コストの削減を目指します。

残念なことに、クラウドでは事態はさらに複雑になります。 サービスを制御できない可能性があります。 接続をハードコードしたり、従来の方法で作業を実行したりできない場合があります。 多少の痛みはあります。 しかし、よく言われているように、「苦労なくして得るものなし」ですよね? ユーザーの行動、接続性、適切な帯域幅を計画する必要があります。

移行を少しでもスムーズにするために、開始するための重要な 7 つの手順をまとめました。

1. 持っているものを評価する

アプリケーションの状態はどうですか? 何個持っていますか? それらはあなたのビジネスにとってどれほど重要ですか? それらはどのような種類のデータを保持していますか? そして最も重要なのは、それらの間の依存関係は何ですか?

アプリがどのカテゴリに分類されるか考え始めましょう。 次の 4 つのオプションがあります。

  1. SaaSの導入
  2. クラウドへの移行
  3. ハイブリッド環境の導入
  4. 彼らをそのままの場所に留めておく
2. SAAS へのアウトソーシングに適したアプリを決定する

まずは簡単な部分をやってください。 ポートフォリオ内の仮想商品であるアプリを特定します。 おそらく、たくさん持っているでしょう。 独自の Exchange サーバー、古い HR システム、または自社開発の販売自動化ツールを本当にサポートする必要がありますか? それらはチームの努力や発生する OpEx に見合う価値があるでしょうか? そうでない場合は、営業、人事、生産性、またはその他の適切なソリューションに加入することで、多くのトラブルを回避できます。 大変な作業は第三者に任せましょう。 SaaS を使用すると、すぐに明らかな成果が得られます。

3. 残りを分析して決定する

次に、残りのアプリを評価し、どのアプリをクラウドに移行するか、どのアプリをクラウド用にリファクタリングするか、どのアプリをそのまま維持するかを決定する必要があります。

次の質問を自問してみてください。

- アプリ X を移行すると、いくつの機能が壊れますか?
- データストアはどこにありますか?
- 依存関係は何ですか?
- どのようなネットワーク サービスを使用していますか?
- 動作させるために通常の手順やプロトコルの回避策が必要なアプリはどれですか?

多くのアプリでは、これらの質問に対する答えが得られます。 他の人にとっては、実際に動かしてみるまで答えが分からないかもしれません。 破損のリスクが高く、依存関係が複雑でよくわからないほど、アプリをそのままにしておく可能性が高くなります。

これらの依存関係をマッピングしたら、それを文書化します。 これは、クラウドに保存されるアプリが少数の場合でも役立ちます。

4. 標準化する

アプリ配信ポリシーを調べて、標準化と自動化の機会を探します。 すべてのアプリケーションに対して手動で調整された構成ではなく、限られた数の標準負荷分散ポリシー(たとえば 10 個)を用意する必要があります。標準化されたストレージ層を決定します。 標準化されたネットワーク サービスを定義します。 標準化の利点について開発者と話し、彼らのコミットメントを得ます。 迅速かつ簡単に展開できるようにテンプレートを作成します。

5. アクセスを簡素化し、安全にする

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

認証とセキュリティの問題もあります。ほとんどの企業は従来、アクセスを決定するためにアプリ制御ではなくネットワークを使用してきました。 パブリック クラウドでは、これまでになかった新しい ID およびアクセス管理テクノロジを採用する必要がある場合があります。

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

クラウドに移行する場合、構造が静的ではないため、アーキテクチャは異なります。 データベースのようなモノリシック アプリケーションの場合、以前は特定の IP アドレスやその他の定数構造に結び付けられていたメカニズムはクラウドでは機能しません。 常に変化する環境で一貫性を保つために、追加のロード バランサまたはプロキシが必要になる場合があります。 追加の制御ポイントを作成して、誰もが中断することなく一貫してアプリにアクセスできるようにします。

7. 簡単ではないことを覚えておいてください

これは難しいことだ。 冒頭で述べたように、IT アーキテクチャは複雑です。

簡単ではないかもしれませんが、コスト削減(OpEx と CapEx)とスケーラビリティだけでも価値があります。 クラウドへの準備だけで莫大なコスト削減を実現した企業もあります。 既存のアプリ インベントリを評価し、依存関係を分析し、すべてを文書化し、可能な限り標準化および簡素化することで、何を移行し、どのように移行するかを決定するのに最適な状態になります。 

関連コンテンツ
記事

アプリが多すぎることはありますか?

アプリは現代の企業の基盤です。 しかし、良いものでも多すぎると害になるのでしょうか?

記事を読む ›

電子書籍

マルチクラウド成功の原則

効率的で安全なクラウド導入を推進する 5 つの要素を紹介します。 

電子書籍を入手する ›

解決

DevOpsソリューションを自動化する

DevOps、NetOps、SecOps の各チームが互いに速度を低下させないようにしてください。 代わりに自動化を選択します。

ソリューションを見る ›

使用事例

MAXIMUSはF5でオペレーションを合理化

Maximus は、AWS へのシームレスな移行、プロセスの自動化、リソースの解放を実現するために F5 を採用しました。

ストーリーを読む ›