paizaのインフラ刷新の裏側その２

概要

paizaという、サービスにおいて、今後の発展を見越して、インフラ刷新を行いました。
本連載では、paizaで行われたインフラ刷新の段取りや推進、技術選定の話、その他の内情や苦労話を含めて、赤裸々に語っていきたいと思います。
paizaの中って「こんな感じなんだ〜」みたいに、paizaのことを知っていただいたり、
AWSの刷新の実態って「こんなこともあるのか〜」といった気づきだったり、何か還元できるものが一つでもあれば幸いです。

対象読者

• paizaの内情に興味がある方
• AWSのインフラリニューアルに興味がある方

はじめに

paiza株式会社で、エンジニアをやっております。yukimuraと申します。

paizaというエンジニア向けのサービスをご存知でしょうか？

エンジニアの成長につながるような、様々なサービスを展開しているので、聞いたことがある方もいるかもしれません。

aizaのサービスは、2013年にローンチ後、順調に会員数を伸ばし、2023年3月時点で57万人(累計会員数50万人を突破)を突破いたしました。

そのような成長を遂げるpaizaのサービスですが、創業時からあまり変わらないインフラ構成で、このままでは今後のサービス成長を支えきれそうにありません。
すぐに破綻するような状態ではないものの、課題も多かったので、「今後のpaizaを支える新たなインフラ基盤へと進化を遂げよう！」という気持ちで過酷で楽しい物語は始まります。

本稿では、具体的なBeforeのインフラ構成とAfterのインフラ構成を紹介したいと思います。

paizaのインフラ刷新前

細かいところは割愛していますが、刷新前は、以下のような構成でした。

• まず、テスト環境と同じAWSアカウントであり、別れておりません
• また、VPCは、テスト環境と同居してしまっています
• EC2インスタンスに必要なミドルをインストールして動かしています(EC2の中身はAnsible管理)
• どういうサブネットで構成されているかは、ポリシーがなくよくわかりません
• また、VPCは、テスト環境と同居してしまっています(大事なことなので、2回書きました)

paizaのインフラ刷新後

同じく細かいところは割愛していますが、刷新後は、このようにしています。(継続改善中です。)

• AWSアカウントは別アカウントで分けており、誤操作の可能性が低くなっています
• アカウントが別れているので、VPCのみならずあらゆるリソースは別管理です
• ここには書いていませんが、terraformでコード管理することで、構成の同一性を担保しています
• サブネットの構成ルールはポリシーとテンプレートを定めて新しくVPCを切った場合も同一構成としています

刷新にむけたネットワーク構成ポリシーの整備

刷新前のところでは、触れておりませんが、VPCに切られている、サブネットやルーティングテーブルは、とても悲惨な状態でした。。
具体的には、サブネットの切り方が何も考えられておらず、CIDRで切れることをいいことに、それぞれのサブネットが、それぞれ別のサブネットマスクを使っているような状態でした。
個人的には、クラスレスアドレスが利用できるにしても、特に明確な意図がない限りは、クラスA,B,Cを軸にサブネットを切っておくのが無難かなと思っています(私のような古い人は、それで慣れてしまっているせいかもしれないですが)
また、ルーティングテーブルも、正直たくさんありすぎて、ちょっとでも触ったら壊れそうな状態でした。

このような状態では、ネットワーク周りの修正もいれづらいですし、あとから見た人が把握するのが困難になるため、インフラ刷新にあたって、基本となるネットワーク構成を整理しました。
構成としては、大旨以下のような形で、新しくVPCを作った場合は、基本的にこの構成になるようにしています。

Availability Zone等割愛している部分もありますが、VPCをする場合は、基本的にこの構成に合わせるようにして迷いづらく、一度把握したら、他のVPCも把握しやすいようにしています。

さて、AWSアカウントを分離していく方針と、移行後のネットワーク構成も整理できてきたので、次回以降の記事では、実際に刷新していく中身について紹介していきたいと思います。