こんにちは。株式会社パイプラインの濱田です。

前回はクラウドエンジニアにとって大切な基礎体力のうち、ネットワークの基礎知識が重要であることを述べました。

オンプレミスのネットワーク設計経験があり、その設計思想をクラウドへどう持ち込むか、あるいはどう応用するか、という観点も大事ですが、はじめてオンプレミスからクラウドへシフト＆リフトする際など、クラウドのお作法とミスマッチが起きて運用負荷が上がってしまう事例も見聞きします。

これをどうしたら防ぐことができるのか、考察してみましょう。

オンプレミス→クラウド移行 考慮ポイント

オンプレミスのネットワーク・サーバー環境をクラウドへ移行する際に考慮したいポイントをいくつか例示します。

機能要件・非機能要件を詳細に言語化しよう

まず、現行環境がどういった思想で設計されているのかをできるだけ精緻に言語化することを強くおすすめします。

要件定義書を読んですべての正解がそこに書かれているのが理想ですが、実際には運用フェーズにおいて追加要求や仕様変更、バグ修正や新たなセキュリティ脅威への対応などでシステムは常に変化しています。

移行元となるシステムがあるからと言って、前例踏襲さえすればよいというわけではないことを強く認識し、クラウド環境設計を行う際の要件定義に活かしましょう。

仮に前例踏襲が要件にあったとしても、決してこれを否定するわけではなく、なぜその前例が要件になりうるのか、業務影響や技術的な観点から言語化すると、運用引き継ぎの品質が向上します。

性能要件は恒常的なモニタリングから

クラウド環境のサイジングはオンプレミスとは違い、(課金さえすれば)単体のハードウェアが性能上限になることはありません。

しかし、現在のハードウェアを充分に活かしているかどうか、感覚ではなく数値で判断できるよう、監視ツールなどを用いた性能情報取得を行いましょう。

あわせて、WEBサーバーであればアクセス解析も行い、どのアプリケーションがいつ（曜日、時間帯などの規則性、あるいは突発的なイベントなど）グラフのスパイクを描くのかにも注目しましょう。

その機能、その制約は何に由来していますか？

これはオンプレミス、クラウドともに言えることなのですが、ある機能や制約事項が業務要件に由来したものなのか、現行環境を維持するために実装したものなのかを見極めましょう。

この見極めをしないまま長年運用してきたシステムで「なぜあるのかわからない機能があり、廃止するのが怖くてそのまま移行した」「不要だろうと思って廃止した機能が実は年次で動いたバッチだった」といったような話を聞くことがあります。

オンプレミスからクラウドへ、あるいはクラウド間でシステム移行を行うことは、新規にシステムを構築するよりも難易度が高く、エンジニアの腕の見せ所といえましょう。

なぜなら、移行に失敗することはすなわち「今までできていたことができなくなる」ことを意味するからです。

しかし、失敗することを恐れるあまりに、不要なものまでも盲目的に移行することは様々なリスクも新環境へ持ち越してしまうことにもなります。

---

まずはエンジニアデビューしたい、という方は、3ヶ月間学びながらお給料が貰える AltX キャリテク!の門を叩いてみてはいかがでしょう。

https://www.kcct.co.jp/careetec/