自社サービスのAWSインフラをフルリプレースした裏側 by イドヒョン

数年間で成長してきた自社プロダクトが、増加したトラフィックを処理できない問題に気付き、
AWSインフラをリプレースすることにしました。

2016年に立ち上げられた自社プロダクトは、利用者数と利用コンテンツがどんどん増えていきました。
さらに、利用プラットフォームもウェブとガラケーからモバイルアプリへと拡大し、利用者の利用頻度も急激に増加しました。
具体的には3年で利用組織が6倍、ユーザーが6倍になりました。
それに伴って、サーバーへのトラフィックも急増し、ボトルネックになりそうな状態に陥りました。

しかし、サーバーは今後も増え続けるトラフィックをうまく処理できず、高いレイテンシで応答するか、最悪の場合システムがダウンするほど可用性が低い状態でした。さらに、障害へのトラブルシューティング対策も不十分で、不安が募りました。

そこで、AWSインフラの問題点を洗い出し、対策案を立てました。
固定台数のEC2インスタンスで対応していたサーバーを、
負荷分散と自動スケーリングが可能な仕組みに変更しました。
さらに、サーバーで行われていたさまざまな処理をサーバーレスに移行し、
自動フェイルオーバーの仕組みも導入しました。
特に、数年間継続して運営してきたサーバーを含むインフラを一新するにあたり、
インシデントが起きないようにリリースまでの流れに検証の内容をしっかり盛り込みました。

• インフラ設計 ‐ 草案
• インフラ構築・実現検証 ‐ デモ
• サーバー簡素化
• システム改修
• プロビジョニングツール導入
• 構築・確認・検証 ‐ デモ
• インフラ設計 ‐ 最終版
• 構築・確認・検証 ‐ 本番
• インフラ切り替え
• ヘルスチェック・イベント可視化

その結果、トラフィックが増えてもうまく分散できるインフラが整い、
低レイテンシでサービスを提供することができるようになりました。
また様々な検証のおかげで、プロダクトに障害を起こさずにインフラのリプレースが実現できました。

このセッションでは自社プロダクトでインフラのリプレースを行った背景ときっかけ、そして実際にリプレースを行った流れを紹介させて頂きます。