はじめに
Hello World! RevCommのバックエンドエンジニアの矢島です。
今回はMiiTelのアーキテクチャや技術スタックと開発・運用体制についてご紹介します。
MiiTelってなに？
アーキテクチャや技術スタックの話題に入る前に、簡単にMiiTelについて紹介します。
MiiTelはAI搭載型クラウドIP電話です。
電話業務の可視化・分析を行うことで、セルフコーチングの機会を提供し、教育コストの削減・業績向上を実現するSaaSとして、電話営業やコールセンター、カスタマーサクセスなどの現場に導入いただいています。
MiiTelはそのサービスの性質上、特に平日の日中は業務のメインアプリケーションとして活用されることが多く、数秒でもサービス停止が発生するとお客様の業務にダイレクトに影響してしまいます。そのようなことが起きないように、適切な技術選定と設計を行わなければいけません。
MiiTelは大きく以下の3つのコンポーネントに分けることができます。
- 電話機能を提供するPBX
- 電話の音声データの話し方解析・言語解析を行う機械学習モデル
- 通話データを管理・可視化するWebアプリケーション
RevCommではこれらのコンポーネントをすべて内製しています。
この記事では全体的なアーキテクチャや開発・運用体制に触れつつ、主にお客様に常に利用されているアプリケーションに焦点を当て、MiiTelを支える技術スタックとその変遷を紹介していきます。
※当記事に記載された情報は公開時点（2023年5月）のものになります。
MiiTel アプリケーションアーキテクチャと技術スタック
MiiTelには、管理者がユーザーを管理・電話の応答ルールの設定などを行うMiiTel Adminと、ユーザーが電話・通話履歴の管理・解析結果の確認などを行うMiiTel Analyticsがあります。
認証基盤アプリケーションは今後のサービス展開でも共通化できるよう、MiiTelアプリケーションから切り出して開発を行っています。
バックエンドの言語はPythonを採用しています。機械学習や音声認識分野でPythonが多く使われていることや、グローバル進出時に海外のエンジニア採用に有利であろうという観点から採用しました。
WebフレームワークにはDjangoを採用しており、機能単位にアプリケーションを分割して開発しています。
MiiTel はZoomとも連携しており、Web会議を自動で取り込んで解析し、会議の録画を解析結果とともに確認・管理できます。
MiiTelインフラアーキテクチャと技術スタック
要件
- 平日の日中に集中するアクセスを低レイテンシーで処理する
- 高い可用性を実現する
- 機能実装に集中できるインフラ構成を実現する
冒頭にも記載した通り、MiiTelはサービスの性質上、平日の日中にアクセスが集中します。そして数秒のサービス停止であっても大きな影響を及ぼします。
そのような柔軟なスケーリングと高い可用性を、なるべくリソースの管理に人員を割くことなく実現するためにさまざまなAWSサービスを活用しています。
- CloudFrontとLambdaでのキャッシュ・アクセス制御をすることでバックエンドアプリケーションへの負荷を削減
- Application Load Balancerでのヘルスチェックと負荷分散
- ECSでコンテナ化されたアプリケーションをデプロイ
- Fargateでのマネジメント不要なスケーリング
- 負荷分散の観点からECSサービスを役割によって分割
- OpenSearchで膨大なデータを横断して検索する機能の実現
- SQSで音声解析システムとの連携を疎結合に実現
もちろん初めからこのようなアーキテクチャになっていたわけではありません。現在の構成に至るまで改善が繰り返されてきました。
そこで、MiiTelアプリケーションバックエンドの核を実行する赤枠の部分について、過去からの変遷を踏まえながら詳細を紹介します。
MiiTelアプリケーションバックエンドのインフラアーキテクチャの変遷
EC2の時代
創業から1年程度は、EC2のみを使ったシンプルな構成でした。
この画像は2017年11月のSlackでのやりとりです。
当時はスケーリングも考慮しつつ、スピードを意識した開発をしていた様子がうかがえます。
ECSの導入
ユーザー数が急速に増えていくなかで、スケーリングの課題が発生しました。
都度EC2インスタンスを管理しするのは運用に工数がかかり、スケールできないリスクが高まります。
そこで、以下のような改修を行いました。
- アプリケーション環境をEC2からFargateに変更する
- ECSのAuto Scaling を利用し、実行するタスク数を自動的に増減させる
この改修により急激なリクエストの増加にも耐えられるようになりました。
ECSサービスを役割で分割
ECSでタスク数をオートスケーリングするようになったことで、スケーリングは容易になりました。
しかし当時は、すべてのバックエンドへのリクエストを同一のサービスで処理していました。
それにより、サービス成長によりデータ量が多くなるにつれて、リクエストの中でも高負荷のものが他のリクエストのレイテンシーに影響を及ぼすようになってきました。
そこで、以下のような改修を行い、現在の構成になりました。
- リクエストの内容によってCloudfrontのオリジンとビヘイビアを使い、異なるロードバランサーにリクエストを振り分ける
- それぞれのロードバランサーのターゲットを異なるECSサービスにする
この改修により、高負荷なリクエストが増えても他のリクエストのレイテンシーに影響させないようにすることができるようになりました。
加えて、RevCommのTerraformを利用した現在のインフラ構築・運用の基盤ができたのもこの頃です。
次は、RevCommのインフラの構築・運用方法をご紹介します。
インフラ構築・運用方法
RevCommのインフラ構築・運用はヒューマンエラーを最小限にしつつ、よりスピーディーなリリースを実現するための工夫がなされています。
スピーディーなリリース
- 基本的に機能の開発者がそれに必要なリソースをつくる
- 職種によらずInfrastructure as Code (IaC) でリソース構築を行うことを推奨している
RevCommにはインフラチームが存在しますが、アプリケーションのAWSリソースの構築には原則関わりません。アプリケーションの機能に必要なAWSリソースはアプリケーション開発者が構築・運用に責任を持ちます*1。
このように機能開発からリソース構築まで一気通貫で行うことで、インフラチームのAWSリソース構築待ちといった時間が削減できています。
また私が入社して驚いたのが、フロントエンドエンジニアでもAWSリソースを構築・運用できる人がいることです。
RevCommには、在籍しているメンバーが市場価値の高いエンジニアになってほしいという方針があり、それが体現されているなと思いました。
多くのメンバーが担当できる技術領域を広げられる構築・運用体制になっていることで個人の成長に繋がっています。組織としても、属人化による運用コストの増加を防ぎ、スピーディーなリリースを実現できます。
ヒューマンエラーの最小化
RevCommでは、IaCのツールとしてTerraformとServerless Frameworkなどを利用しています。
以下の運用体制を敷いてヒューマンエラーを最小化するようにしています。
- GitHub Actionsで、terraform fmt, validate, planを自動実行し結果を出力
- 特定のリソースはGitHub Actionsで applyを自動化
- AWSアカウントに紐づくIAM roleで開発者が直接applyできるリソースを制御
実際の開発フローは以下のようになっています。
今後のMiiTelインフラアーキテクチャの展望
MiiTelを支える技術スタックやアーキテクチャとその変遷、開発・運用体制を紹介しました。
MiiTelのアプリケーションやインフラにおいては、今回ご紹介した以外においても様々な改善が繰り返されてきました。
そして今やMiiTelは日本だけでなくインドネシアでも提供されており、今後は北米進出も目指しています。
今後の更なるサービス成長や世界展開を視野に、インフラアーキテクチャにおいてはリージョンをフル活用して可用性と耐障害性を高められる構成にアップデートするPoCを実施しています。
まとめ
今回は、MiiTelを支える技術スタックと開発・運用体制というテーマで、記事を書きました。
2022年7月に入社してから、日々アーキテクチャやシーケンスのキャッチアップをしながら開発に奮闘している私としても、全体を俯瞰するいい機会となりました。
この記事をご覧いただいて、少しでもRevCommに興味を持っていただけたら、ぜひ採用ページもご覧ください。
*1:インフラチームは、インフラの全体最適化や、VoIPのためのインフラ構築・運用、セキュリティの強化などを行っています。
