対話型音声AI SaaS IVRyのインフラの歴史をSREの観点から眺める
2024年10月に入社をしてSREやアーキテクチャといった領域を担当しているab（ @abnoumaru ）です。入社番号は138番です。
この記事は IVRy Advent Calendar 2024の白組 10日目の記事です。紅組はYuya Machidaさんが「広義のプロダクトマネージャーがアウトカムを出すために大切なこと13選」という記事を書いています。
白組9日目はナカザワさんによる「入社半年を振り返る〜暗黒の再オンボを経て〜」という記事でした。
11日目はキックさんが「チンチロに勝ったらAI FAXが完成した話」というタイトルで記事を公開する予定です。 お楽しみに！
はじめに
この記事ではIVRyのインフラの歴史をSREの観点から眺めて当初の出来事やエピソードを深堀ります。なおここでいう「SREの観点から眺める」は「信頼性の階層にあげられているサービスの信頼性を高める要素に関わる施策や技術選定に注目する」ということを意味しています。
なぜこの記事を書こうと思ったか？
IVRyは2020年にリリースされてから4年以上サービスが続いており、様々な歴史を積み重ねてきました。入社したばかりの自分からすると、日々改善や調査のために設定を見たり、メンバーから話を聞くたびにその歴史を感じる瞬間が多くあります。
個人的に新しく入った組織やアーキテクチャを知る上で、過去の経緯や作った人の思いといった歴史も一緒に知ることが重要であると考えています。これはお互いのナラティヴ（解釈の枠組み）を把握できて、改善提案や日々のタスク推進で発生するコミュニケーションの役に立つと考えているからです。併せて、単純に自分がアーキテクチャやそれを取り巻く組織の過去の経緯などを把握するのが好きなので、このような記事を書いています。
IVRyの現状やアーキテクチャを知って「そういうのあるよね！」と共感していただいたり、「IVRyで働いてみたいな…！」と感じていただけたら幸いです。
2020年
βリリース・正式リリース
IVRyは2020年7月にβ版として提供を開始して、同年11月に正式リリースされました。
現在も利用するドメイン ivry.jp をwhoisで確認するとβリリースの直前に取得しており臨場感が伝わってきます。
% whois ivry.jp | grep "登録年月日"
[登録年月日] 2020/06/16なお2024/11/26に開催されたアーキテクチャカンファレンス2024における弊社町田の登壇にて、電話の機能を提供するエンドユーザ側とルールなどを設定するクライアント側のDBを共有せずに分割する構成が紹介されています。この構成はこの頃からすでに利用されておりました。
当初はエンドユーザ側はECSとDynamoDBとマネージドな構成、クライアント側はECSとRDSは利用せずに、EC2にアプリケーションとPostgreSQLが相乗りする構成でした。立ち上げ当初からつながって当たり前な電話のインフラにはECSとDynamoDBを採用して運用しやすくスケーラブルな構成にすることでサービスレベルとコストと運用のバランスを上手く取っています。
2021年
初めてのスパイク
2021年の6月には初めてのスパイクが発生しました。原因はコロナウイルスのワクチン予約に関する問い合わせ電話でした。これはIVRyが社会的なイベントでスパイクが発生するプロダクトであるという特徴を理解する事例になります。ここですごい点はDynamoDBのオートスケールにより負荷に耐えきれている点です。前述した「サービスレベルとコストと運用のバランスを上手く取っています」がしっかり効果を発揮しています。
インフラ基盤の改善
スパイクだけではなく利用してくれる方々も増えて、今後どんどんプロダクトが大きくなることを見越してIVRyのインフラ基盤の改善が行われた年でもありました。この改善の背景には、IVRyが生まれるまでにいくつもプロダクトを試していたこともあり、AWSアカウントやVPC等のリソースが一部他サービスと共存されていたことや前述の通りEC2にPostgreSQLをホスティングしていたことなどがあります。今後のサービスの爆発的成長に耐えて、アジリティ高く開発できる未来に投資して行われた思い切ったインフラ基盤の構成変更があったおかげで、現在は事前に負荷増加が予想されるタイミングで迅速にスケールできる環境になっています。
Terraformを利用してインフラのプロビジョニング、IaC管理が行われるようになったのもこのタイミングで git log --reverse をすると最初のcommitを確認することが出来ます。
% git log --reverse
commit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Author: XXXXXXXXXXXXX <XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX>
Date: Wed Aug 4 11:50:21 2021 +0900
Initial commit
2022年
サービス拡大に伴い性能やキャパシティを整備
利用者の増加に伴いキャパシティや性能の問題に直面した年に見えました。これらの話は12/8にアドベントカレンダーに投稿をしたEMのyuriさんの過去記事に詳しく記載されています。
主にDBの話に注目すると、クエリのパフォーマンスを意識して作っていたが、一箇所複雑なクエリを利用していた部分がデータ量の増加によりパフォーマンスの課題が顕在化したこととあります。またこれまでコストの見合いで利用していなかったリードレプリカ導入やスケールアップなどを実施しています。なおこの時点で変更前のRDSはdb.t3.microでした。DynamoDB側に負荷の高い処理が流れている特徴もありますが、2年前まではそのサイズだったのかとサービスの成長に驚かされました。このように実際にトラフィックを受けながら必要なものを必要なだけ利用してコスト意識高くサービスを運用していくことは、まさにエンジニアの腕の見せ所だなと思いました。
監視・オブザーバビリティの整備
この年はオブザーバビリティを高めるためにダッシュボードを眺めていきたいという話題からDatadogの利用も始まりました。IVRyではDatadogが監視だけではなくQAの観点でも大活躍しておりその始まりも2022年です。
2023年
インフラ専任メンバーの入社
それまで開発を実施しながら正社員や業務委託のエンジニア、ときにはCEOの奥西がインフラに携わっていましたが、2023年についにインフラ専任で担当するメンバーが入社しました。それまでインフラのリソースは緊張感の高いものでCEOの奥西が待機していました。この入社後しばらくしてインフラリリースで奥西の待機がなくなったというエピソードもあります。
2024年
メンバー増加に伴い整備が加速した1年
そして2024年12月現在、エンジニアの人数は34名になりました。インフラを含むSREやPlatform Engineeringと言われる領域に軸を置くメンバーは2024年1月時点で3名でしたが、現在は7名に増えており、インフラ/基盤周りの改善が急速に実施されています。例えば以下のような改善が今年始まり、実際に利用され始めたり、運用しながら日々改善を進めています。
TROCCOの導入とデータ基盤の整備
CI/CDパイプラインの改善
Terraformのステート分割とAtlantisによるGitOps化
AWSのSSO化とIAMユーザを大幅に削減
Observability向上に向けてDatadog APM導入
SLOの導入と運用の開始
不要なAWSリソースやTerraformの定義削除が加速
PagerDuty導入
ちなみに自分は主にAWSのSSO周りやDatadog周辺の施策をここ2ヶ月で行ってきました。詳細は以下に書いてあるので興味がある人は是非見てください。
最後に
いかがでしたでしょうか？メンバーに聞いた話やSlack、Gitのログなどを頼りにIVRyのインフラの歴史を振り返ってみました。
初期から関わる立場ではありませんが、これほど社会で利用されるサービスになる過程を知って、胸に来るものがありました。自分も新しい歴史を作っていけるように日々精進したいです。
そしてIVRyではそんな歴史作りを一緒に楽しんでくれる仲間を絶賛募集しております。
電話という高いサービスレベルが求められるサービスと向かい合いながら、社会の課題を解くためにAIを実サービスで利用している非常にエキサイティングな環境で一緒に働きませんか？
