「MiiTel（ミーテル）」のサーバレスインフラアーキテクチャ

音声コミュニケーションの課題をテクノロジーで解決するSaaS「MiiTel（ミーテル）」を開発・提供しています。営業・サポートなどのビジネス通話における内容を可視化・解析することで、チームの生産性向上や業務改善を支援しています。

MiiTel Scan to Callについて

従来の通話方法における手間やコストを削減し、新たなコミュニケーション体験を提供したいという思いから、「MiiTel Scan to Call」を開発しました。

「MiiTel Scan to Call」はスマートフォンでQRコードをスキャンするだけでアプリインストールや特別な設定なしにブラウザからすぐに無料で通話を開始できるサービスです。

サーバレスのインフラアーキテクチャについて

どのような形でサーバレスアーキテクチャを導入・活用しているか

全く新しいサービスなので早く世に出してフィードバックをもらいたかったため、なるべくシンプルにコストをかけずに早く構築することを考えてサーバーレスを導入しました。

既存のプロダクトと重なる部分（認証、データベースなど）があったため完全にシンプルなサーバーレスアーキテクチャとすることはできなかった。CloudfrontやRDSの採用、VPC内にLambdaを置いているなどはこれが理由です。

また、将来サービスが伸びたときサーバーレスではない選択肢を取りやすくできるようにコンテナ内にWebアプリケーションを立てるという形を採用しました。

当初設計していた時はなるべくインフラコストをかけないことを考えていましたがレスポンス速度などの改善のために一定コストをかけるという方向に舵を切りました。それでもECSなどと比べると圧倒的に安いです。

設計や運用における工夫・課題とその解決策

アーキテクチャ設計やCI/CD、ローカル開発、セキュリティ、監視、トラブル対応など、日々の運用で直面している／していた課題と、それに対する工夫や捉え方などを項目別にまとめると、下記になります。

レスポンス速度の改善

• Cold Startの回避
  • Provisioned Concurrency はコスト面での懸念がありましたが、コンテナが軽量であることと実行時間、頻度を考慮するとScan to Callではコスパの良い手段でした。
• シークレットの読み込み
  • リクエストが来た時にSSMから都度読み込まなければならなかったので時間がかかっていました。キャッシュ導入と一括取得で対応しました。
  • LambdaとRDSの接続管理
  • RDSとの接続をプールしておくためにRDS Proxyを間に挟みました。
• メモリ増強
  • Lambdaの課金体系はメモリ量×実行時間によって決定されます。メモリ量は増えましたが実行時間を短縮できたのでコストも抑えたまま改善できました。

Lambda上でのWebアプリケーションフレームワークの扱い

• ローカル開発をしやすくするために、またLambda以外に移行したくなったときに早く移行できるようにコンテナ上にWebアプリケーションを構築するという形を採用しました。Lambda Web AdapterというLambdaの拡張機能を使って実現しています。

その他

• 元URL（ホスト名）が取れない
  • ヘッダに付与するcloudfront functionを用意してホスト名をWebアプリケーション内やログで使えるようにした。
• CLIが実装できない
  • 常時起動ではないためCLIを実装して外部からコマンドを叩くようなことをしたい場合、その処理用のLambdaを新たに立てる必要があった。
• ログの外部出力
  • Datadogにログを出力するためにDatadogが用意したLambdaの拡張機能やライブラリをインストールしました。

今後の展望や取り組み予定について

サービスが伸びたときにサーバーレス以外の選択肢を取ろうと考えていましたが、ある程度サービスが伸びてきたにも関わらず今のところ現状のアーキテクチャで全く問題なく稼働しています。そのため、現状の構成で以下のようなコスト削減やコールドスタート時間削減などを検討しております。また、１AWSアカウントあたり同時起動数1000台までのクォータがあるので引き上げリクエストをするのか違う方法にするのかも今後考えていく予定です。

• コスト削減
  • 現在設定しているProvisioned Concurrencyは固定ですが、プロビジョニング数をApplication Auto Scalingで管理する
• コールドスタート時間削減
  • 非同期化
  • Lambda分割