坂本です。rexcornuでは主に自社プロダクトの管掌をしています。
皆さんメリークリスマス！いかがお過ごしでしょうか？
今回は自社プロダクトであるTechMatchのインフラを刷新してモダン化しましたので、それについて書いてみたいと思います。
これを書くにあたり、このインフラ刷新対応のほとんどは以前こちらの記事 を執筆してくれた高橋さん、社員エンジニアの木本さんでやり切っていただきました。
紆余曲折があり大変なプロジェクトで、一度中止の検討をした時期もありましたが、まずはこの壮大な対応をやり切っていただいたお二人をはじめ、移行期間中にあたたかく協力してくれた開発関係者、プロダクト運営の関係者、営業関係者の皆さんに深い感謝の意をお伝えしたいと思います。
はじめに：TechMatchとは
rexcornuが提供するTechMatchは、2,000社から提供される、25,000人を超えるアクティブエンジニア情報を用いた調達支援サービスです。現在はプロフェッショナルサービスの顧客企業向けにTechMatch、フリーランスエンジニア向けにTechMatch for Freelance を展開しています。
インフラを刷新した目的・背景
TechMatchの初期の開発は主にアプリケーションエンジニアによりインフラの整備も含めて対応していました。AWSを利用することにより、サーバやDB、NWといったWebサービス提供に最低限必要なインフラは構築でき、その上に必要なアプリケーションをリリースして2023年4月12日に無事サービスインを迎えました。
ただ、インフラについては、以下のような課題がありました。
- EC2でフロントエンドとバックエンドのサーバを構築してしまったため拡張性が乏しかった
- フロントエンドがCDN上で動作していなかったため、外部からの攻撃に対してリスクが高く、フロントエンドに求められる性能の最適化もできていなかった
- リリース後、担当者が別案件の担当になるなどでプロジェクトを離任したり、ドキュメントをあまり残していなかったことなどから、著しく属人化していた
- 本番環境とステージング環境が同じアカウント内に作成されており、さらに同じVPC内に構築されていたため、本番環境のセキュリティを担保するために本来厳しくする必要のないステージング環境のアクセスも必要以上に制限する必要があるなど、非常に効率が悪くなっていた
- 非機能の標準的な考え方が整理されておらず、今後のサービス追加でさらにインフラが複雑になり散らかっていくことが懸念された
この他DevOpsの観点でも、以下のような課題を抱えていました。
- ローカル環境の構築がOSに依存しており、MacのエンジニアとWindowsのエンジニアで開発環境のセットアップに関するナレッジが相互に活かせない
- 各環境へのアプリケーションのリリースも手動でやっていて、エンジニアの作業ミスによるリスクや内部不正のリスクも高い（特に本番環境）
今回のアクション
今回の刷新の主なアクションアイテムは以下です。
- IaCによるコード管理
- まずは兎にも角にもインフラの構成を可視化し、属人性を排除すること
- 構成情報の可視化で類似環境の構築を速やかに行えるアセットを手に入れること
- AWSのOrganization化
- 全てのアカウントをOrganization配下で管理し、コスト管理や権限管理を集約
- アカウントに紐づく個別IAMユーザの廃止＆AWS IAM Identity Centerの採用によるアカウント横断での包括的なアクセス管理
- 各プロダクトの本番環境、ステージング環境など、環境ごとにアカウントを作成
- 顧客情報を保持している本番環境はアクセス権を厳格に運用
- ステージング環境は開発効率が維持できるように広めのアクセス権を付与
- 運用監視など共通的なものようにcommonのアカウントを作成
- フロントエンドのCDNの活用によるバックエンドとの完全分離
- TechMatchはAWSのCloudFrontとS3を採用
- TechMatch for Freelance はNext.jsで開発しており、SSRも考慮する必要があるので、Next.jsの開発元が提供しているVercelを採用（当然SSRにも対応）
- コンテナの活用によるCI/CDの整備
- ローカル環境、ステージング環境、本番環境のいずれもOS非依存で開発、運用できるようにコンテナを採用し、ローカルはDocker、AWS上はECSを採用
- ローカル環境はMac or WindowsのいずれでもDocker上にコンテナを持ってきてインストール
- バックエンドはコンテナイメージを、フロントエンドはプロジェクトをそれぞれCI/CDでリリース
刷新後のシステム構成
今回の刷新後のシステム構成はこちらです。
起きたことあれこれ
本番移行作業前に起きたこと
- このインフラ移行プロジェクトだけでもリスクが高いにも関わらず、これと並行して新規のサービス（TechMatch for Freelance）の開発や、アーキテクチャの変更が必要になる機能追加を同時並行で走らせてプロジェクトの複雑性を高めてしまった
- 移行対応の遅れが発生した影響で、プロジェクト期間中に旧環境のRDSの証明書期限切れ対応を緊急で対応する必要があった
- ネットワーク構成の変更により、アプリケーションサーバとデータベースサーバの疎通がうまくいかなくなった
- ECS上でcronや環境変数がうまく設定できなくなった
- ECS上でメールの取り込みができなくなった
- ECS上にあるアプリケーションからファイルのダウンロードができなくなった
本番移行時に起きたこと
以下の事象は全て一時的なもので、現在は全て正常に運用されております。
- ドメインが移管がもれて、TechMatchサービスサイトが一時的に表示されなくなったり、一部メールの取り込みができなくなった
- リリース直後に意図せぬサーバ停止が発生して一時的にサービスにログインできなくなった（設定調整と再起動で復旧）
- Slackアプリがしばらく動作しなくなった（ドメイン移管による浸透期間が影響？）
今後の課題
今回の刷新で多くの重要な問題が一気に解決し、かなり効率的で管理しやすいインフラになりましたが、依然として以下のような課題は残っています。
- 課題というよりは残タスクとして、一部のAWSリソースがTerraformで管理されていない：何が記載されていないかは明確になっているので属人化まではしていないが、管理効率が下がったり何かの際にシステムがうまく動かないことにつながりやすいので早めに整備したい
- ECSを採用しているにも関わらず、一部のバッチ処理の影響でAuto Scalingをすると業務上の不都合があるため、設定がオフになっているバックエンドのコンテナがある：業務影響は軽微だが、アーキテクチャ的に最適ではないため整理したい
- 一部のレガシーな業務システムの残存：現時点ではプロダクトのアカウントの配下にあるため、業務システム用のアカウントを個別に作成してそこに移行するか、外部クラウドサービスの利用を前提とした運用変更を検討するか（スマートなのは後者）
- インフラではないが一部システムのモノリス構成が残存：フロントエンドとバックエンドを分離（に伴いインフラの分離も対応）する
- リポジトリやCI/CDをエンジニアにとって開発体験の高いGithubに移行する
おわりに
これでTechMatchのサービスがモダンなインフラになり、プロダクトがよりしなやかにより強くなっていける土台が整ったと思います。rexcornuは祖業としてエンジニアのプロフェッショナルサービスを提供している会社ですので、自社のエンジニアが新しい技術にチャレンジする環境としても自社プロダクトを活用していければと思います。
今回、インフラ面は整備されましたが、アプリケーションアーキテクチャの負債、使われていないあるいはリスクな高い機能の負債など、まだまだ整備すべきものはあるので、引き続きドラスティックに最適化していきます。
今回はインフラネタでしたが、次はどこかで上記のようなアプリケーション系のネタやプロダクトマネジメント関連のネタも書いていこうと思いますので、おたのしみに。
rexcornuでは、これからの会社の成長を共にしてくれる仲間を募集しています。