数百台のオンプレVMからAmazon EKSへの移行

ツール導入前の課題

オンプレミスで運用していた数百台の仮想マシンのスケーラビリティと運用コストに課題を感じていました。

• 仮想基盤のノード追加のために、ハードウェアの調達、ラックやネットワークの設計などに時間を要するため、迅速に基盤をスケールさせることができない
• ハードウェア故障などに対応するための24時間/365日の保守・運用体制が必要だった
• 仮想マシンは用途ごとにカスタムされた構成で構築・運用されており、新規サーバーの構築のために大きな手間と時間がかかっていた

どのような状態を目指していたか

• キャパシティが不足した際に迅速にスケールできること
• 新しいサーバーを迅速に本番投入できること

• Amazon Elastic Container Service (ECS)
• Amazon Elastic Compute Cloud（EC2）

EKS移行以前からAWSを利用しており、他のクラウドはマルチクラウド構成における複雑性や、レイテンシの影響を考慮し、移行の選択肢には入りませんでした。 重視したのは、移行にかかるコストとリスク、そして移行後に得られる恩恵のバランスが取れていることでした。

オンプレミスからクラウド基盤への移行はインフラの大きな変更です。 そのため、その他の要因によるリスクを抑えるためにもアプリケーションのアーキテクチャに大きな改修を加えることなく移行できる自由度が必要でした。

また、移行前にAWS環境にKubernetesを構築して少数のサーバを運用していた実績があり、知見が蓄積している分、設計ミスなどの想定外の事象が起きるリスクも比較的抑えられていたことも大きかったです。

改善したかった課題はどれくらい解決されたか

導入前に抱えていた課題は、ほぼすべて改善されたと感じています。

どのような成果が得られたか

基盤に起因する障害がほとんど発生しなくなりました。 オンプレミスで運用していたころは、ハイパーバイザーやロードバランサー、スイッチといった基盤起因のトラブル（障害に至らないケースも含めて）が年間数回程度発生していましたが、障害の発生頻度は大きく減りました。 オンプレミスでの運用では、障害に至らないハードウェア故障も都度検知し対応していましたが、 移行後は、稀に通知されるEC2のリタイア予告を確認しノードを入れ替える程度で済んでおり、心身共に負担が大きく削減されました。

移行作業によるサービス停止時間を最小化し、切り戻しができる移行を行うために、オンプレミスからの移行を少しずつ行いました。

設計段階からネットワークのレイテンシに悩まされましたし、過渡期にはオンプレミスにKubernetes環境を構築し、AWSとオンプレミスで同一構成のアプリケーションを稼働させるという複雑な構成を取りました。

トラブルによる切り戻しは数度発生しましたが、切り戻しを想定した設計と移行計画を立てていたことにより、移行計画全体は予定通り完遂することができました。

Kubernetesは既存の中～大規模アプリケーションを、大きなリアーキテクチャを施さずクラウドへ移行させる上で、最適な選択肢の一つだと思います。 ただし、EKSはコントロールプレーンはフルマネージドですが、ノードの管理はユーザが行う必要があり、定期的なバージョンアップを含むノードの保守運用が必要となります。 また、自由度が高く複雑な構成が取れる分、Kubernetesの学習コストは比較的高いといえるでしょう。

もし、シンプルなコンテナ基盤が欲しい場合や、新規アプリケーションでAmazon Elastic Container Serviceなどに合わせた設計を行うことができるのであれば、運用負荷の少ないフルマネージドサービスを選択するのが賢明かもしれません。