はじめに
any株式会社 CTO波多野(@hatamasa1988)と申します。
最近はTwitterでもほぼ発信しておらず。久しぶりの外部発信です！！！
今回はQastのインフラアーキテクチャの変遷についてご紹介しようと思います。
とはいってもまだまだ半分もやりたいことができてない状態なので、シード〜シリーズAに向かってインフラアーキテクチャがどういった段階を経て来ているのかを読んで、へぇ〜と声をあげてもらえたら嬉しいです。
やったことを全て書くと情報量が多すぎるのである程度絞って書いています。
(知る限り)初期アーキテクチャ
サービス開始して間もないころのアーキテクチャです。
アプリケーションはReact, Pythonのスタックになっていて
サービスとして0→1が終わり、機能追加をフリーのエンジニアさんのみでやっていた頃です。
声を大にして言えないのですが、、、
- ひとつのEC2で複数のモジュールやミドルウェアが起動している
- 全てが単一障害点(当時はこれでもサービス停止しなかった)
- プロフィール画像がEC2上に配置されていたり（当時はデータ量も小さくてこれでも耐えれた）
- AWS ShieldやVPC系のセキュリティ設定のみで一定のインフラセキュリティを担保(当時はこれでも許容されていた)
という状況で、見た瞬間に「あー、できたばかりのスタートアップなんだなー」という香りがプンプンする構成になっていました。
その他に図からは読み取れないですが、同じELB(と書いてあるがALB)でメインサービスと社内管理画面をルーティングしていたり、ひとつのEC2内部にいくつものモジュールが入ってたりしました。
単純にインフラにも言える単一責任の原則が守られていない状況でこれもまたシード期のスタートアップならではの(?)選択だなーと1人の夜にしみじみとissueをリストアップしたのを覚えています笑
セキュリティ整備後のアーキテクチャ
ここまで来るとシード期のスタートアップにしては一気に進んだ感ありませんか？
このフェーズでやったことは
- ステージング環境の作成
- EC2上のプロフィール画像をS3に移行
- CircleCIでCI/CD構築
- IPアドレス固定化のため NLB導入
- AWSのセキュリティ系サービス導入
アーキテクチャ変更は伴いませんでしたが、アプリケーションレベルではこの時期にネイティブアプリのiOS(SwiftUI)とAndroid(Kotlin)がwebと同じAPIを使用して爆誕しています。
ステージング環境を整備
まずはデプロイで自分がハラハラしたくなかったので！！！
これは自分にとっては大きな第一歩でリリースのたびに緊張で胃がキリキリすることがなくなりました。言い過ぎですがそれくらいのインパクトはありました笑
プロフィール画像をS3に移行
EC2上の画像のディレクトリを丸々削除してしまう完全にNGなトラブルがあり、大半は定期取得していたEC2のAMIからバックアップできたのですが復元できなかったプロフィール画像についてはお客様に謝罪をして投稿しなおしてもらうという障害も発生させてしまいました。
これを機にS3へプロフィール画像を移行することを決意した形になります。
言い訳はできませんが、やることが多すぎて障害が発生するまで後回しになりがちなポイントは計画に組み入れて潰しておかないとダメだなと反省しております・・・。
CircleCIでCI/CD構築
ステージング環境整備と同じく、もっとスムーズに、ストレスなくデプロイしたかったので！！！
背景はCircleCIは導入経験があって、かつこの頃はGithubActionsにSSHでのデバッグが備わってなかったので構築やデバッグのしやすさからCircleCIを選択しました。
今では後述するリアーキのモジュールはGithubActionsで回してます。
IPアドレス固定化のためにNLBを導入
セキュリティ要件が厳しいお客様の受注に伴って導入しました。
AWSでIPアドレス固定の方法はいろいろありますが、一番手っ取り早いのがNLBでしたが、後のWAF導入がNLBにはできずに再度ALBに戻すことになりました・・・。
WAF、ロギング系、監視系、脆弱性スキャン等のAWSのセキュリティ系サービスやEC2へHIDSを軒並み導入しました
今までよりも大手のお客様の受注が決まるにつれて社内の資産(ナレッジ)を守るためのセキュリティ要件が厳しくなってきたて整備せざるを得なくなってきました。こんな簡単に一通りのセキュリティサービスを導入できるなんてやはりAWS様様です。
我々はAWSのおかげでアプリケーションに集中できるというわけなので、皆様毎晩手を合わせて感謝してから寝ましょう！！！！
WAF導入の途中でIPアドレス固定化のために導入していたNLBではWAFが適用できないことを知り、GlobalAccelerator + ALB ヘ再度変更を行ったのはなかなか重い変更作業でした。
# Next.js, NestJS時代 Phase1
この時期からリアーキを進めることにしました。
リアーキの内容はこちらでも触れさせてもらっていますので興味ある方はご覧ください。
このフェーズでやったことは下記です。本当はグッと理想系に近づけたかったのですが結果発生した事象ベースで都度リファクタをする形になってたので、中途半端な形でアーキテクチャ選定してしまったり、再リファクタが必要な状態にはなっています。
スタートアップのアーキテクチャは常に非連続なリファクタの繰り返しかと思うので、この段階を経験したことがある人たちも多いのではないでしょうか？
この時期にやったことは
- アプリケーションのリアーキにECS Fargate導入（フロントはNext.js、バックエンドはNestJS、APIはGraphQL導入）
- Qastの利用指標が見えるユーザー側のダッシュボード機能提供のためにBigQueryを導入
- 外部連携用のcallbackを受け取るAPIサーバーを分割
- プレビュー用のファイル変換処理のサーバーを分割
アプリケーションのリアーキにECS Fargate導入
これを機にフロントはNext.js、バックエンドはNestJS、APIはGraphQLのアーキテクチャに。
Next.js, NestJSはECSのfargateに徐々に移行をし始めました。
EC2ガチ世代の私からすると中身が見にくいdockerやフルマネージドサーバーは最初こそ抵抗ありましたが、いざ運用してみるとリソースもデプロイするだけで変更できる、Blue-Greenデプロイは標準搭載、オートスケールもコンソールから設定となんと楽ちん・・・。メンテコストがほぼかかっておらず控えめに言って神です。
強いて言えばデバッグがちょっとだけ辛くなったくらいです。
Qastの利用指標が見えるユーザー側のダッシュボード機能提供のためにBigQueryを導入
BigQueryへの夜間データ登録がテナント数とデータ量が多く夜通しバッチが実行し続ける形に・・・。
初導入のBigQueryということもあり、手探り状態で運用。
しかも結構夜間バッチがエラーすることも多くリカバリ作業も頻繁に発生しながらの運用に。
今でこそ徐々に安定してきましたがまだまだ夜間バッチはリファクタしないと今後耐えられない雰囲気がぷんぷんします。
まだまだ中途半端な形になっていますが少しずつは進んでいます。
Next.js, NestJS時代 Phase2
簡易的な図ですがアプリケーションのスタックはこちら
この時期を境にリアーキが一気に進みます。
やったことは下記
- 検索基盤リニューアルでSNS + SQS + Opensearch の構成を導入
- cron実行バッチのリアーキにAWS Batch導入
- 非同期処理の実行基盤をLambdaにリアーキ
検索基盤リニューアルでSNS + SQS + Opensearch の構成を導入
リアーキ開始からすこし少し経って検索エンジン強化PJがスタートし、検索基盤のリニューアルが始まりました。
それにより SNS + SQS + Opensearch の構成を導入しています。
検索基盤の移行PJはかなり重い開発でしたが大きな障害もなく移行することができました。（感謝）
こちらでも触れさせてもらっています。
cron実行バッチのリアーキにAWS Batch導入
cronの定期実行バッチはコンテナ化しAWS Batchに移行を開始しています。
Lambdaに移行する選択肢もありましたが、定期バッチは長期実行の可能性があるためLambdaにするには並列化して処理時間を短縮する必要がありました。
今回の移行では処理の見直しまではリソースを取れずにAWS Batchにコンテナ化だけして移行することにしました。
非同期処理の実行基盤をLambdaにリアーキ
APIからキックされる非同期処理についてはLambdaの環境にリアーキしています。
AWS CDKをラップしたsst(Serverless Stack)というフレームワークを導入していてものでTsでAWSリソースの配備や実行処理を記述できる様にして非同期処理のLambda環境のデプロイを行なっています。
リアーキが終わるまではEC2群の整理に終わりが見えませんが現状のインフラアーキテクチャはこの形になっております。
実際に内部はまだまだガチャガチャな状態で最適化へ向けて整備をしていく必要があります。
今後の展望
今後はリアーキを早期に終わらせるために、管理ページ、アプリ/SP画面と複数リニューアルPJが開始されます！
それによってアプリケーションは旧スタックの構成が終了し、新スタックへリアーキ完了します。
内部改善ではまずRDSのAurora移行やOpensearch Serverless移行を行う計画を行なっています。
外部連携用のAPIや内部のバッチなどの非同期処理のモジュール系については現段階ではPythonのままですが、今後はモジュールごとのビジネス要件に従って適切な技術スタックを用いてリニューアルをかけていこうと考えています！！！
というかこの記事を書きながらインフラアーキテクチャを見直したら、、、本当にやりたいことが多すぎる！！！笑
まだまだアーキテクチャを0から設計する機会は多くありますし、アーキテクチャもビジネスの進化に伴って非連続な改修を行なっていかないといけないので、ガンガン設計して手を動かしたい方にやってもらいたいです！！！
より深く知りたい人はカジュアル面談までお越しください！！！
最後にanyではエンジニアを募集しています。
複数のリアーキ、リニューアルPJに関わりたいエンジニアからのご募集をお待ちしております！！！
TwitterDMでもwantedlyからでもじゃんじゃんご応募ください。波多野がカジュ面いたします。
最後まで読んでいただきありがとうございました！！！
Discussion