今、楽待では全システムをAWSへ移行するという大きな挑戦の真っ最中です。
インフラ専任エンジニアとしてその中心に立ちながら感じている「難しさ」と「楽しさ」についてお伝えします。
楽待のインフラの現状と課題
当社のシステムの多くはESXi上の仮想マシンとして稼働しています。
より正確に説明すると物理ホストやvCenterなどはデータセンター事業者が管理しており、当社はvCenterにログインし、決められたリソースの範囲内で仮想マシンを作成し、運用する形になっています。
AWSやGoolg Cloudなどに慣れたエンジニアには中々想像しづらいかもしれませんが、すごく簡単に説明すると、ほぼオンプレミス環境と思ってもらっても差し支えありません。
オンプレミス環境と違いがあるとすれば、物理ホストを管理しないで済むのでデータセンターに行くことはないということくらいです。
※これはインフラ専任のエンジニアとしては大きな違いで非常にありがたいことではあります
そのような環境のため、主に以下のような課題がありました。
(1). 物理ホスト1台当たりのリソースサイズを超えたスケールアップが出来ない
(2). AWSのようなAPIが揃っていないので、自動化がしづらい
(3). マネージドなコンテナオーケストレーターがない
(4). S3のようなオブジェクトストレージがない
AWSなどのパブリッククラウドと比べてしまえば、課題はキリがありません。
また、これらの課題を解決する仕組みを自前で用意することも確かにできるかもしれません。
例えば、Cephなどを利用してS3互換のオブジェクトストレージを自前で構築するなど上記の課題の全てを自前で構築することによって解決することも理論的には可能かもしれません。
しかし、当社の規模でそこまでして、果たして運用しきれるのか？ 運用まで含めたコスト面でメリットがあるのか？ と疑問がありました。
※ちなみに当社のインフラは数名で対応していますが、インフラ専任は私1人です
そこで当社は元々の課題の解決 + AI利用を前提とした将来的なデータ活用のため、本気でAWSへ移行することを決意しました。
ちなみにここ最近追加したマイクロサービス的なものや画像の保存先は既にAWS上で構築済みだったりします。
目指すべき未来
移行対象となる仮想マシンが多数(※約50台)になるため、現時点では全てをどのように移行するかを計画出来ている訳ではありません。
ただ、基本的な方針としては以下のようなものを掲げています。
(1). 運用負荷を下げる
=> なるべくマネージドサービスを使う
=> サーバレス化出来るものはサーバレス化する
(2). IaCを推進する
現時点で実際に移行の準備が進んでいるものもあります。
その移行の準備が進んでいるサービスの開発環境ではDockerを利用してるので、ECS Fargateで運用していくことを前提として準備を進めています。
また、push通知機能に関してはSNS + Lambdaをベースにサーバレスな構成に作り変えることを想定して、検証を開始しています。
最後に
インフラの全面的なAWS移行のようなチャレンジングなプロジェクトはインフラ担当として大きな責任も感じていますが、同時にワクワクしている部分もあります。
また、アプリケーションも含めて全て内製している当社なので、移行段階でやっておいた方が良いと考えられるアプリケーションの変更も随時、他のエンジニアとその場で相談しながら進めることが出来ることが個人的には嬉しい点です。
そして、インフラ専任の私1人の力では全てを成し遂げることが出来ないため、普段はアプリケーション担当のエンジニアの方達にもAWSリソースの構築という面でも協力してもらって、開発部全体でこのプロジェクトを進める体制になっています。
そういう意味では、普段はアプリケーションを担当しているが、インフラも触ってみたいというエンジニアにも当社の今の環境は合うのではないかと思っています。
このようなインフラの全面的な移行というフェーズはなかなか経験出来るものではないので、このような貴重な経験をしたい、そして是非協力したいと思ってくれるエンジニアは採用ページから応募してもらえると非常に嬉しいです。