• よくわかるクラウド
  • AWS
  • 運用
  • 移行
  • オンプレミス

AWSに移行した環境の最適化のススメ【1】AWS移行と運用の考え方

近年のクラウド化の流れを受け、システムのAWS移行を検討中の方も多いと思いますが、移行後の運用についても検討されていますか? AWS移行後もオンプレミスと同様に運用は必須となっています。
本連載記事では、AWSへの移行とその後の運用を行う上で重要なポイントを解説します。

連載「AWSに移行した環境の最適化のススメ」

  ▶【1】 AWS移行と運用の考え方
【2】 AWS最適化の進め方
【3】 AWS最適化の具体例

AWSへの移行戦略

システムやアプリケーションの移行を進める際に「どんなシステムを」「どこに」「どうやって移行するか」の3点を検討されると思います。移行先としてAWSを検討する場合、まずはAWSのサービスについて理解する必要があります。
AWSでは、IaaSやPaaSからSaaS/BaaS/FaaSのようなコンテンツやファンクションを載せるだけで稼働するようなサービスまで、多種多様なラインナップが用意されています。そのため、どんなサービスを、どのように組み合わせて構成するかなど、移行戦略を立てる上でしっかりと検討する必要があります。

この移行戦略については、AWSのウェブサイトにて、以下の6つのアプローチが紹介されています。

1.リホスト (「リフトとシフト」)
2.プラットフォーム再編 (「リフト、ティンカー、シフト」)
3.再購入 (「ドロップアンドショップ」)
4.リファクタリング/再設計
5.使用停止
6.保持
引用元:アマゾン ウェブ サービスに移行する

それぞれを簡単にまとめると以下のようになります。

リホスト (「リフトとシフト」)
⇒現在の環境をそのまま移行し、徐々に最適化する

プラットフォーム再編 (「リフト、ティンカー、シフト」)
⇒コアの部分を変えず部分的に最適化した上で移行する

再購入 (「ドロップアンドショップ」)
⇒現在のシステムやアプリケーションを使用廃止し、新しいシステムやアプリケーションに移行する

リファクタリング/再設計
⇒現在のシステムやアプリケーションを見直し再設計した上で移行する

使用停止
⇒不要なシステム・アプリケーションの使用を停止する

保持
⇒移行しない

当社でもお客様のAWS移行をお手伝いしていますが、この6つ移行戦略のうち最も多く採用されるケースは「リホスト(以下、リフトアンドシフト)」です。
リフトアンドシフトとは、先に記載したとおり、現在のシステム構成をほぼ変更せずにAWSへ移行(リフト)し、運用の中で徐々に最適化(シフト)していくという考え方です。
リフトアンドシフトに関してはこちらの記事にて紹介しているので、併せてご覧ください。

参考:AWSへの移行、リフトアンドシフトで初めてでも手間なく移行するコツ

リフト段階では、マネージドサービスはほとんど利用せず、AWSのIaaSサービスであるAmazon Elastic Compute Cloud(EC2)とAmazon Virtual Private Cloud(VPC)を中心に活用することになります。この段階でももちろん、ハードウェアの保守などから開放されたり、地理的に離れたデータセンターに自由にサーバーを配置して冗長化をはかれたり、必要な時に必要な分だけインフラを調達できるなど、AWSのメリットを享受できます。しかしAWSを最大限に活かすためには、リフトしただけで満足せずに、AWSが提供するマネージドサービスを取り入れていくなどの最適化を進めることが必要です。

ITインフラの運用を考慮した設計

では、AWSの最適化を進めるためには、どのようなことを考えるべきなのでしょうか?

ITインフラの運用では「障害の検知」「障害からの復旧対応」「障害への恒久対策」の3つに関わる業務に多くの時間を割きます。そのため設計段階では「障害の予防」が重要視されます。ただし現実的にはすべての障害を未然に防ぐことは不可能であり、障害発生時の影響範囲をいかに減らすかを考えながらITインフラの設計をする必要があります。
しかし、その影響範囲を減らすためには、サーバーやネットワーク機器の冗長化などの対策が必要であり、対策を実施すればするほどコストは増大します。つまり「障害の予防」と「コスト」はトレードオフの関係となっており、この妥協点をビジネスへの影響度から探ることがITインフラ運用を考慮した設計のポイントとなるのです。

AWSへリフトした段階で起こり得る障害とは?

よくお客様から「AWSに移行すればシステム障害は発生しなくなりますよね?」と聞かれます。結論から申し上げると、AWSでもオンプレミスと同様に、障害は発生します。ただし、AWSでは障害発生時の影響範囲を減らすための機能や選択肢が、いくつも用意されていることが大きな違いです。

AWSにシステムを移行したリフト段階で発生しうる障害としては、以下が挙げられます。

インスタンス障害
⇒使用している仮想サーバーが正常に稼動しなくなることがあります。EC2の場合、インスタンスを停止して起動すると別のハードウェア上で立ち上がるという仕様になっているため、停止・起動を行うと正常には戻りますが、障害は発生するといえます。

アベイラビリティゾーン(AZ)間通信の一時的な遅延または瞬断に起因する障害
⇒地理・電源・ネットワーク的に分離されているデータセンター群であるAZは高速専用線で接続されていますが、この通信が一時的に遅延・瞬断することがあります。

メンテナンス通知を見逃したことによる予期しない再起動
⇒EC2にはハイパーバイザーのアップデート等の理由でメンテナンスが入ることがあります。このメンテナンスは、事前に期日までにインスタンスの再起動を実施してくださいという旨の通知があります。指定された期日までに、再起動をしないと自動的に再起動がかかります。そのため事前の通知を見逃してしまうと、意図しないタイミングで再起動が発生することになります。

アクセス急増に起因するメモリ枯渇
⇒割り当てているメモリを使い切ってしまうとLinuxでいうところのOOM Killerが走って、プロセスがダウンすることがあります。

上記のような障害に対しては、ビジネスへの影響度を考慮した上で、AWSユーザー自ら対策を検討する必要があります。

次回の記事では、AWS最適化の進め方についてより詳細に解説します。

連載「AWSに移行した環境の最適化のススメ」

  ▶【1】 AWS移行と運用の考え方
【2】 AWS最適化の進め方
【3】 AWS最適化の具体例

※本記事の内容につきましては2019年1月時点での情報です。

AWSの活用事例やノウハウなど役立つ資料を提供

オンプレミスからクラウドへの移行を成功させるポイントやミズノ株式会社様の導入事例など、AWSの利用を促進するノウハウの詰まったお役立ち資料を提供します。ぜひご活用ください。

おすすめの記事

おすすめのカテゴリ