チーム全員がほぼAWS未経験。2つの国を横断するサーバーをAWSに移行した話。

運用コストを下げ、本当に必要なところにリソースを集約すべきだと考え、任せられるものはクラウドのリソースを活用しようと考えました。数ある選択肢の中で、AmazonのAWSを使うか、GoogleのGCPを使うかが候補に残りました。

レアジョブの開発チームは、日本とフィリピンの２拠点にあります。
ユーザーは日本に生徒、フィリピンに講師が存在しています。お客様が日本にもフィリピンにもいる環境なのでサーバを設置に相当する場所が重要になります。

日本であればAWS,GCPともに東京リージョンを活用することができますが、フィリピンには残念ながらリージョンがなく、AWSを利用しようとすると東京かシンガポールが最も近い場所になります。当然この距離はサイトの応答速度に影響をあたえ、ユーザーエクスペリエンスに直結するので、近ければ近いほど良いのです。

GCPには台湾リージョンがあったので、フィリピンにとって近い距離なのでGCPですとレイテンシが短くなりました。

ただ、それを踏まえた上でもフィリピンの開発チームは、GCPに対してあまり積極的ではありませんでしたよね。

当時、インターネットで情報収集するのにGCPの情報はまだ充分になく、今後課題に直面した時、解決していかなければならないが情報量というのがキーになります。情報量の多さも追い風となり、AWSに決めました。

システムを移行するということは、新しい環境に一からシステムを作ることを意味します。古すぎるシステムのため、構築手順書は陳腐化されており、その上にどんどんシステムが追加されて行ったこともあり、巨大なバームクーヘンと化していましたね。

まずは、一つ一つ設定やスクリプトを移植し、テストを行いAWSで動かすための地道な作業を行ないました。また、このタイミングで古いシステムもAnsibleにてコードで管理するようにしました。
 
AWSへ切り替えるメンテナンス時間を短縮するため、事前にDNS設定をRoute53に移行し、既存環境からAWS環境をVPNにてつなぎ、ホストMySQLとRDSのDBの同期を行いました。
 
AWSのサービスにはメンテナンスがあるため、サービスを継続するためにワンポイントフェイラーを作らないように冗長化を意識して設計しましたが、Wordpressを冗長させる構成は運用も考えたときに対応するのが厳しいとの判断となり、一台構成になりました。（この時点で、AWS EFSサービスが東京リージョンでの利用ができなったので、現在であればEFSを利用した形とる想定になります）
 
DBについては元のシステムが古いバージョンを利用していました。昨年バージョンアップを行う予定で計画していたが、問題が発覚しバージョンアップができていない状況でした。そのため、AWS移行時にもその問題が残った状態であったため、RDSの既存と同じバージョンに移行することとなりました。

既存のバージョンではレプリカのマルチAZ化が行えないため、参照用レプリカRDSを負荷分散を設計する方針としました。
 
当初NLBを利用して分散することが考えましたが、NLBが指定できるのはIPまたはEC2インスタンス単位であるため、RDSを指定することができませんでした。
 
検証を重ねた結果NLBとRDS間にHA Proxyサーバを入れて、多段での負荷分散を行うことで冗長化を実現させました。

レアジョブ英会話はサービス開始当初から現在も少しずつ機能を追加したり、新しいサービスのリリースを行っています。

インフラを刷新するには、インフラチームのリソースのみならず、開発チームや企画、カスタマーサポートなど多くの部署との連携が必須になります。移行に時間をかけてしまうと、新しいサービスを開発する人員を確保できなくなってしまう・・・。

安全かつ最速で実現するには、どのくらいの期間が必要か。CTO山田を交えてチームで検討した結果、６ヶ月でしたね。その後、経営や関係部署に対して、技術とサービスや事業運営への影響を伝え、正式に決行が決まりました。

プロジェクトの本質は、”インフラの運用コストを下げ、新しいシステムを作りやすくすること”に尽きます。AWSへの移行は手段にすぎません。

その本質で考えると、全てのサーバを本当に移行する必要があるのかという問いが生まれましたよね。

移行すべきものは頻繁にリリースがあるシステムです。またそれに紐づくシステムに絞りました。

それに加えて今回の移行プロジェクトでは、やらないことも明確にしました。AWSフルマネージドの機能は非常に魅力的です。しかし、今の段階でAWSフルマネージドのサービスは学習コストに加え試験にも時間がかかってしまうので、無理に使わず今回は見送ろうとなりましたね。

先にも言いましたが、旧環境とAWSはVPNを繋ぎルーティングの変更を行い、接続可能な状態を確立させます。まずはネットワーク周りの整備を行い、その後AWS上にサーバを作っていきます。その際にはAnsibleにて構成をコード化させました。

DNSにて向き先を旧環境からAWS環境へ切り替えられるように整えた上で、移行当日までは既存環境と並行して、AWS側の各サーバにコードをデプロイを行い、常に最新状態を保つようにしました。

データベースに関しても旧環境のDBをマスターとしてRDSにレプリカを作り、常にデータを同期取るように行い、移行しやすい状況を作りました。

今回は別のレアジョブ英会話とは異なるプロダクトになるため、移行したAWSのVPCではなく、別のVPCに構築することを決めました。

新しいプロダクトにも生徒がいれば、先生のような利用者がいます。
ただシステムを作っただけではサービスを運用していくことはできません。
これを克服するためにフィリピンの開発チームに日本人のエンジニアを駐在させ、日本にはフィリピン人のエンジニアを常駐させ極力コミュニケーションや文化の問題が妨げにならないよう体制を作りました。

スマートメソッドプロジェクトでは基盤となる部分を個別に開発し、それをプラットフォームとして他のシステムでも利用できるように新しく基盤を作っていくことにしました。
 
マイクロサービスのアーキテクチャにて設計し、プログラム部分の言語はGOを採用しました。

サーバ構成としては、ApiGateway、Lambda、ALB、EC2、Redis、RDSを利用してインフラ環境を構築し、既存のシステムで諦めたフルマネージドを活用する形にしました。
 
サーバの設定は引き続きAnsibleでコード化を行い、セキュリティグループ設定、ネットワーク構成、インスタンス、ElastiCache、RDSの構成をCloudFormationにて構築するようにしました。
 
このプラットフォームを利用するフロント側は生徒側、講師側で異なるVPCでそれぞれのシステムを作り、お互いがデータのやり取りをAPIだけで行う形に構築しました。
 
その際、生徒側は日本のプラットフォームチームが、講師側はフィリピンのプラットフォームチームが管理できるように分けました。そのことにより、フィリピン側のスタッフにも責任感を持たせることができるようになりましたね。

モバイルはFireBaseを使うつもりでいたが、AWSでAppSyncがリリースされ、こちらの利用を検討しました。https://aws.amazon.com/jp/about-aws/whats-new/2018/04/aws-appsync-now-ga/
 
AWSのみで一気通貫できればシナジーも生まれやすいという点もあり、急遽設計をし直しました。結果的にAppSync、lambda、DynamoDBといった形でAWS内のフルマネージドを活用する形で設計することができました。

スマートメソッドのシステムはある程度、フルマネージドを活用したものになりましたが、AWSへ移行したレアジョブ英会話ではまだまだやるべきことがあります。

6ヶ月で移行完了を優先させたため、フルマネージドが十分に使えていない、という点ですね。この点は今後、アーキテクチャの設計から見直し対応していく必要がありますよね。

それを考えると、今はまだスタート地点にたっただけにすぎませんね。

振り返ってみると、AWS移行が成功したことにより多くの選択肢を得ることができましたね。これによって、開発スピードを向上させる事ができます。

抜本的なインフラ変更は、会社やチームにとって成長痛のようなものだと考えています。痛みは避けられないが、この苦しみが我々の成長を促進させています。