はじめに

こんにちは。42 Tokyoというエンジニア養成機関の 2023 年度アドベントカレンダー 6日目を担当します、在校生のkohkuboと申します。

この記事では、今年の7月から働いているスタートアップでインフラを担当してみて、どんなことを考えて、どんなことをやったのかをまとめてみました。

生成AIスタートアップでインフラ運用してみて

今年の7月からKinkakuという会社でインフラエンジニアとして働いています。サービスの立ち上げから、インフラの構築、リリース、運用まで、インフラという観点で一通りのことを経験することができましたので、その経験を共有したいと思います。

インフラで触ったリソース

インフラはGoogle Cloudを使っています。クラウドの選定から行いました。Google Cloudを選んだのはベンチャー支援のクレジットが大きかったことが決め手です。これは後からわかったことですが、他のクラウドよりもGPUリソースが取りやすいというメリットもありました。AWSは触ったことがありましたが、Google Cloudは初めてだったので、最初は両者の違いに戸惑いました。ドキュメントを読みつつ、試行錯誤しながら、インフラを構築していきました。

触ったリソースは以下の通りです。Google Cloudの一通りのリソースを触ることができました。

Cloud Build
Cloud Run
Cloud Storage
Cloud SQL
Eventarc
IAM
Cloud VPC
internal application load balancer
external application load balancer
Cloud Armor
Security Command Center
Secret Manager
Cloud Logging
Cloud Monitoring
Workflows
Google Kubernetes Engine
Vertex AI
Batch
Artifact Registry
Cloud Functions
App Engine

運営しているのが生成AIがメインのサービスなので、GPUを使う処理が多く、CPUなら用意されている様々な手段が使えないだけではなく、有用な先行例があまり存在しなかったので、やってみないとわからないことが多く苦労しました。

インフラの基本方針

最初から作り込まない、完璧を目指さない
コードが複雑にならないように問題は極力インフラで解決する

少ないメンバーで運用しているので、やりすぎないことを意識しました。また、サービス側のコードをシンプルに保つため、インフラで解決できることは極力インフラを使うという方針で行いました。インフラでの解決 > コードでの解決という優先順位でなるべく管理するコードが少なくて済むように意識しています。

こだわりすぎないように意識はしましたが、以下は基礎としてしっかりと構築しました。

IaC
継続的デリバリー
検証、テストが行いやすい環境の構築
エラーが起きたときに、通知を行うシステムを作る

ここに書いたこと以外にもセキュリティ等は言うまでもなく必須なのでやるべきことはやりました。

IaC

Terraformや、SDKを使って、インフラをコード化しました。ここに関しては、設定できないもの以外は、すべてコード化し属人化しないように徹底的に行いました。

Google Cloudでは、公式の機能で環境をTerraformのコードとして落とせるので便利でしたが、結局はドキュメントを読みながら、コード化していくことが多かったです。

継続的デリバリーの導入

CI/CDですが、リリースを第一目的とするため、簡単なLintやビルドテストを除いて、自動テストの作成は後回しにしました。42での経験からテストの重要性は身にしみにて理解していますが、リリースを優先したことと、メンバー間でテストに対する共通認識を持つには、ある程度の実害を感じて進めていくのが良いと感じたので、後回しにしました。

GitHub ActionsでビルドエラーやLintなどのチェックを行った後、Cloud Buildを使ってすべてのリソースを自動でデプロイするようにしています。ビルド時間は開発体験に大きく影響するので、ビルドの多段化や並列化を行うなどして工夫しています。

モノレポで各機能をマイクロサービスとして扱えるように設計しました。サービスごとにデプロイを行っています。

検証、テストが行いやすい環境の構築

KinkakuではGPUを使う処理が多く、ローカルではテストや検証が行いにくいです。そこで本番と同様の構成で立ち上がる検証環境が作りやすい設計にしました。特定のブランチにPushすると自動で検証環境がビルドされるようにしています。Google CloudはAWSよりもプロジェクトの使い捨てがしやすいので、環境を作るのはやりやすかったです。プルリクエストごとに使い捨て環境が立ち上がるような仕組みもいつか作ってみたいですが、認証の部分がコンソールでしか作成できない等の制約があるので簡単にはいかなさそうです。

ドメイン知識、インフラリソースの管理を1つのリソースで行う

クリーンアーキテクチャの知識や、依存性逆転の原則を使って、処理を行うマイクローサービス郡がドメイン知識やインフラリソースに依存しないようにしました。チーム開発で機能追加時にメンバーがインフラを極力意識しないで作業ができるようにしています。DBへのアクセスも限定することでデータの安全性を確保しています。

構造化ロギングの導入

GPUを使ったリソースは、既存のCPUの稼働率を監視するモニタリング基盤のリソースを使用できません。そこでデータ分析がやりやすいように構造化ロギングを導入しました。ログをJsonデータで落としてきてPythonのデータ分析ライブラリで分析し、異常の検出や、モニタリングに活用しています。

エラーが起きたときに、通知を行うシステムを作る

アラートは必須リソースの次に優先して取り組みました。Google Monitoringのアラートは、Slackとメールに対応していますが、社内のコミュニケーションツールはDiscordを使用しているため、Cloud Functionを使ってDiscord通知を行うようにしました。
ログレベルとアラートを紐づけているため、ロギングはGoogle Cloudが対応しているライブラリを使用しなければなりません。特定の文言を入れることでCloud Loggingでの重要度の判定にも使えるので、独自のラッパーを作るという手法もありますが、言語ごとに対応しているログライブラリは異なるので、技術選定の際には意識すると良いです。

Google CloudのGPUリソースについて

GPUリソースの種類と特徴

Google CloudではGPUリソースは主に以下が使えます。

Google Compute Engine
- Google Cloudの基礎となる仮想マシン。AWSでいうEC2に相当する。
Google Kubernetes Engine
- Kubernetesを使ったコンテナオーケストレーションサービス。autopilotというAIを使ったオートスケーリングなどの機能がある。Kubernetes自体、Googleが開発したものなのでGoogle Cloudの中でも力が入っているサービス。
Vertex AI
- Google Cloudの機械学習サービス。GPUを使った機械学習を行うためのサービス。最小インスタンス数は1だがオートスケーリング等の機能があり、簡単なサービスなら十分に使える。
Batch
- Compute Engineを使ったバッチ処理のためのサービス。Workflowと組み合わせて使うことで、バッチ処理を簡単に行える。ただし、起動時間がかかるので、リアルタイム性の高い処理には向かない。

GPUリソースの選定

すべて触ってみましたが、今回リリースしたサービスではCompute Engineを使用しています。オートスケーリング等考えなくてよいVertexAIを使う予定でしたが、サービスが多機能で複雑なため、VertexAIの想定されるユースケースに合いませんでした。GKEのautopilotも使いたかったのですが、GPUのVMに固定でダウンロードされるGPUのcudaのdriverのバージョンが古く、変更できないという使用だったため諦めました。GPUのリソースはどれも登場したばかりで自由度が低く使い勝手が悪いので、結局は自分でゴリゴリと設定しないといけないという印象です。今後リリース予定のAI Canvasというリアルタイム生成AIのサービスではVertexAIを使えないか再び挑戦する予定です。

今後の課題、やりたいこと

コスト

GPUリソースはCPUに比べると段違いに高額です。その分、労力に対して削減できるコストは大きいので色々な工夫をして切り詰めていきたいです。

テスト・内部品質の向上

テストに関して、現在取り組んでいるところです。しっかり書いてリファクタリングし易い環境を作った上で内部品質を上げて開発スピードが上がるような仕組みを作っていきたいです。ただ、テスト自体にもメンテナスコストはかかるので、過剰にならないように注意しながらも、必要十分なテストになるようにしていきたいと考えています。

BigQuery

現状、Metabaseを使ってデータの分析は行える環境を構築しましたが、BigQueryを使っていないので、今後はBigQueryを使って、より詳しいデータ分析をできるようにしていきたいと考えています。FiveTran等も使ってデータを積極的にとってビジネスの意思決定に役立てていきたいです。

モブプロの活用

インフラの大まかな枠組みはできたので、コードの改善や機能追加など、より細かい部分にも入っていこうと考えています。モブプロでキャッチアップしながら、開発を進めていきたいと考えています。

登壇

来年の目標は登壇することです。今年はリリースすることに精一杯で、記事を書いたり、アウトプットができませんでした。発信していかないと有益な情報も集まらないと感じているので、来年は登壇することを目標に頑張ります!

まとめ

スタートアップでインフラを担当してみて、どんなことを考えて、どんなことをやったのかをまとめてみました。まだまだ課題は多いですが、コミュニケーションを積極的に取りながら連携して、これからも頑張っていきます。

おわりに

明日は、みんな大好きsnaraが記事を投稿します。お楽しみに！