BONXはconsulを使ってます
はじめまして、チケイのスケーター齊藤と申します。
昼食前に駒沢公園のスケートパークに滑りにくのが日課となっております。
今月は小さいクウォーターパイプでバックサイドディザスターを決めるのを目標に日々汗を流しております。
今日は雨のためスケートに繰り出せなかったのでBONXのインフラで使用しているconsulに関しての記事を書いてみることにしました。
consulとは、Service Discovery and Configuration made easy. (サービスの検出と設定を容易に行える仕組み)
以下、このconsulをBONXでどう活用しているかを書きたいと思います。
BONXのインフラ概要
AWSにどっぷり浸かっています。
AWSで稼働させているのは、主にサービスで使用しているAPIサーバ,VoIPサーバの2つとwebサイトのbonx.coです。
APIサーバはRoR、VoIPサーバはGO言語でスクラッチビルド。
deploy環境を統一することで運用負荷を減らすためにAPIサーバとVoIPサーバはElastic Beanstalkに乗せており、webサイトはS3にコンテンツを置いて素のEC2インスタンスから参照させています。
全体的な構成はRDS,Elasticacheなどを使用した一般的な感じとなっております。
APIサーバはユーザ情報やルーム情報といった会話に必要な機能を担い、VoIPサーバは通話部分の機能を担っております。
BONXでのconsulの使いどころ
- APIサーバからVoIPサーバを検出(抽出)する
VoIPサーバのscoreを保持しておりルーム数が一番少ないVoIPサーバを検出し新規ルーム作成時に割当を行う
マルチリージョンでVoIPサーバを稼働させるときは、これにGeoIPの判定が加わります - VoIPサーバのダウンを検知してフェイルオーバーする
バッチサーバからconsul watchを起動してVoIPサーバのダウンを検知したらフェイルオーバータスクが起動
consulの構成
- serverは2台で1台は専用サーバでもう一台はバッチサーバに相乗りをさせている
推奨サーバ数は3台ですが今現在は2台で稼働 - APIサーバ、VoIPサーバがclientとなる
- VoIPサーバの検出ができるように、VoIPサーバはサービス登録を行っている
AWSのマルチリージョンにも対応させるためにtagsにリージョンを入れて割当時にフィルタリング出来るようにしている
checksにはVoIPサーバの死活監視コンテンツを入れる
所感
BONXの肝となる通話を担うVoIPサーバの検出と死活監視をconsulを使うことで比較的に簡単に行なえ、ダウン検知も素早く弊社のサービスを運用するには今現在最適なソリューションとなっております。
まだまだ使い倒してはおりませんが、今後はもう少し踏み込んでサービスに役立てていけると思っております。
最後に
チケイは開発チームにジョインしてくれる方を継続的に募集しております！興味がある方はぜひ一度話を聞くだけでもー！ソフトウェアエンジニアだけでなく、ハード側も含めて多数の職種を募集中です！
