見出し画像
Photo by mericanadesico

VoIPサーバーのログをCloudWatch Logsに出力する

BONX

こんにちはBONXでソフトウェアエンジニアをやっているヤマガミです。普段はAndroid開発がメインですが、今回はインフラ周りの作業を行ったので発表させていただきました。

BONXのサービスは複数のwebサーバーやデータベース、各種リソースで構成されています。その中でも最も重要なもののひとつがVoIPサーバーです。今回はVoIPサーバーのログに関する改善事例を紹介していきたいと思います。

VoIPサーバーとは

VoIPとはVoice over Internet Protocolの略です。

BONXはグループトークをはじめとした音声サービスを提供しています。こうしたサービスではインターネット回線を通じて音声データをリアルタイムに送・受信します。これらの仕組みをVoIPと呼び、BONXのグループトークではユーザーAが送信した音声データは一度VoIPサーバーが受信し、そこからユーザーBへと送信されます。（P2Pではない）

ちなみに、BONXではVoIPサーバー以外の代表的なサーバーとしてAPIサーバーがあります。VoIPサーバーが音声データをやりとりするのに対して、APIサーバーはユーザー情報（ユーザー名やe-mailアドレス）などを取り扱っています。

参考 BONXを支える音声信号処理開発のウラガワ

抱えていた問題

さて、そんなVoIPサーバーはサービス開始以来、堅牢かつ強固に動作していました。ただログ管理に関しては以下のような課題を抱えていました。

A. ログを保存してるが検索性が低く、問題発生時に調査時間がかかる
B. UX向上につながるデータもあるが活用されていない
C. エンジニア以外の閲覧が困難
D. 自前で他のサーバーに転送していたがメンテナンス性が低下している

特に検索性の低さは大きな問題となり、些細なログ調査でも場合によって数時間を要するという事態が生じていました。

また、UXやサービス品質を高める上で重要な手がかりとなる情報が含まれているにも関わらず、活用できていないという歯がゆい状況でもありました。

改善案

もちろん改善案は以前よりチームで議論され、ある程度共通認識が形成されていました。しかし理想的な構成にするには開発リソースが確保できず着手できない状況が続いていました。

理想的には、

1. 瞬時にログを探せる
2.  エンジニア以外でも閲覧可能
3. 直感的なビジュアライズで傾向を把握しやすい

としたかったのですが、上記を実現する上では各種ログ解析ツールの導入が前提となり大きな工数が発生します。

そこで現実路線として、Cloudwatch Logsへログ送信を設定するだけで実現できる、

1. 瞬時にログを探せる
2. ただしエンジニアに限る
3. 最低限のビジュアライズはできる

を目指すことになりました。

構築作業

実はすでにVoIPはCloudWatch Logsへログ送信を行なっていました。しかしデフォルト設定ではVoIPサーバーのログは含まれておらず、カスタマイズ設定が必要となります。

前提として、Elastic Beanstalk + Go Platform 環境ではweb-1.log というログファイルが出力され、VoIPサーバーのログはこのファイルに書き込まれます。

画像1

次に上記ファイルを awslogs に監視させるために ebextensions に以下の設定を追加します。

## Custom log (VoIP log file)
files:
 "/etc/awslogs/config/logs.conf" :
   mode: "000600"
   owner: root
   group: root
   content: |
     [/var/log/web-1.log]
     log_group_name = `{"Fn::Join":["/", ["/aws/elasticbeanstalk", { "Ref":"AWSEBEnvironmentName" }, "var/log/web-1.log"]]}`
     log_stream_name = {instance_id}
     file = /var/log/web-1.log

最後にawslogs の再起動を忘れないように以下のコマンドを実行させます。

commands:
 "01":
   command: chkconfig awslogs on
 "02":
   command: service awslogs restart

今回、この部分が漏れていたためdeploy後に再起動しないとLogが送信されないという挙動になり少々ハマりました。また、上記はAmazon Linux を前提にしています。Amazon Linux 2ではコマンドが異なります。詳しくは公式ドキュメントをご確認ください。

余談ですがebextensionsはファイル名順に実行されます。順序が間違っていると起動できなくなることがあるので、ファイル名は実行順で命名するのが無難だと思います。

画像2

そしてどれくらい速くなったのか？

環境構築後、現場のエンジニアにインタビューを実施しました。

ガミ「今回の改善でどの程度速くなりましたか？」

ノリ「そうですね、場合にもよりますが、ちょっとした検索ならコンソールを開いて検索をかけるだけなので数十秒で終わります。ちょっと複雑な検索でも数分ではないでしょうか」

ガミ「なるほど、では以前はどれくらい時間がかかっていたのでしょう？」

ノリ「これも場合にもよりますが、モノによっては数時間。場合によっては半日を費やしたこともあります」

ガミ「なんと、数10倍から数100倍の向上ですね！」

ノリ「ちょっと大げさですが、数字的にはそうなりますね」

ガミ「他にはどういった効果が得られたでしょうか？」

ナイトー「VoIPサーバーごとの接続数やレスポンスタイムなどがより詳細にわかるようになりました」

ガミ「それはどういったことに役立つでしょうか？」

ナイトー「サーバー負荷が把握しやすくなり、システムの安定稼働につながったと考えています」

エイタロ「リアルタイムに接続数が確認できるようになり、インスタンスの増減タイミングに活かせると考えています。うまくいけばUXの向上に繋げられるのではないかと話しています」

ガミ「素晴らしいですね！ありがとうございます」


当然ながらエンジニアは朝から晩までログを調査しているわけではありません。したがって全体の生産性が数10倍から数100倍の向上した、ということではなく、あくまでも部分的に向上したことを意味します。とはいえこうした地道な積み重ねが全体の生産性を押し上げていくのではないでしょうか。

さらなる高みへ

現実的対応が完了したら次は理想的対応です。すでにチームではDatadogを導入すべく作業を進めています。強力なチームメンバーにより着実に進捗していますが、さらに進化を加速するために新たなメンバーを募集しています。

BONXでは、ソフトからハードまで手掛けるHeSaaS領域のスタートアップで共にサービスを作るメンバーを募集中です。
カジュアル面談、採用面談をご希望の方はこちらのフォームよりお申し込みください！