概要
paizaという、サービスにおいて、今後の発展を見越して、インフラ刷新を行いました。
本連載では、paizaで行われたインフラ刷新の段取りや推進、技術選定の話、その他の内情や苦労話を含めて、赤裸々に語っていきたいと思います。
paizaの中って「こんな感じなんだ〜」みたいに、paizaのことを知っていただいたり、
AWSの刷新の実態って「こんなこともあるのか〜」といった気づきだったり、何か還元できるものが一つでもあれば幸いです。
対象読者
- paizaの内情に興味がある方
- AWSのインフラリニューアルに興味がある方
はじめに
paiza株式会社で、エンジニアをやっております。yukimuraと申します。
paizaというエンジニア向けのサービスをご存知でしょうか？
エンジニアの成長につながるような、さまざまなサービスを展開しているので、聞いたことがある方もいるかもしれません。
paizaのサービスは、2013年にローンチ後、順調に会員数を伸ばし、2023年3月時点で57万人(累計会員数50万人を突破)を突破いたしました。
そのような成長を遂げるpaizaのサービスですが、創業時からあまり変わらないインフラ構成で、このままでは今後のサービス成長を支えきれそうにありません。
すぐに破綻するような状態ではないものの、課題も多かったので、「今後のpaizaを支える新たなインフラ基盤へと進化を遂げよう！」という気持ちで過酷で楽しい物語は始まります。
課題感
サービスのユーザー数や、開発を支えるエンジニアが純増し続ける中で、paizaを支えるインフラは、以下のような課題が有りました。
- すべてのインフラリソースが一つのAWSアカウントで管理されており、慎重に検証をしていました。
- ネットワークリソースなどはコード管理されておらず、構成の背景が誰もわからない状態でした
- EC2インスタンスを中心にサーバーが組まれており、スケールアウトの難易度が高い状態でした
- インフラ構成変更のレビューフローや適用フローが整備されておらず、属人的な状態でした
- 個人にIAMを払い出しており、IAMの管理が煩雑化していました
社内で、刷新プロジェクトの重要性を説くための資料の一枚には、このようなことを書きました。
物理的に分かれていると思っていた下水工事(テスト環境用のルーティングテーブル)を開け締めしていたと思ったら、
飲用水(本番サービス提供用のネットワーク)に影響がでて、あわや大惨事。。。といったことが起きてもおかしくない状態でした。
ここからどうなるの？
最終的には、以下のように改善を行いました。
- AWSのアカウントを環境別に分離
- paizaのサービスを支えるインフラは、一通りterraformで管理できるように改善
- インフラ構成変更の運用フロー・レビューフローの整備
- ネットワーク構成のガイドラインやテンプレートの作成
- 大半のEC2を捨てて、ECSへ移行
- 個人ごとのIAMを撤廃して、SSOで管理できるように改善
この記事ではここまでです。次以降の記事で、上記改善に至るまでにどのような感じだったのか、紹介していきたいとおもいます。
Discussion