MOBI VOICE担当の三谷智信です。
今回はMOBI VOICEという電話自動応答サービスで課題になるデプロイの話です。
SIPは通話セッションの確立や制御を可能にするプロトコルであり、その柔軟性と拡張性が電話自動応答サービスにおいて重要な役割を果たしていますが、大きくセッションの確立、変更、終了などの制御情報をやり取りする通信と音声データのやり取りをする通信に分けられます。
SIPメッセージをやり取りするポートは固定で決まっているのですが、音声データのやり取りをするポートは広いレンジでの通信が求められます。
サービス運用をするにあたっては、複数サーバを使用して可用性を担保した状態で行いたいのですが、どのように通信を制御したりサービスのデプロイを行うかということが課題になってきます。
特に電話サービスは急な呼量の増加も発生する可能性があるため、サーバのスケーリングは柔軟にできるようにしておきたいところです。
MOBI VOICEではAmazon ECS（Elastic Container Service）を採用しオートスケーリングを実現し、需要の変動に柔軟に対応しています。
単一のポートだけ考えればよいだけならロードバランサーを使用し、オートスケーリング設定と合わせてリクエストを制御するという構成がよくあるのですが、広範なポートレンジの場合ロードバランサーだけで制御はできません。
そこで動的なIPアドレス変更に対応するため、MOBI VOICEはAWSのCloudWatchEventとLambdaとRoute 53を組み合わせて利用しています。この組み合わせにより、起動中のサーバのIPアドレスを動的に制御することが可能です。
CloudWatchEventでECSのタスクの状態がSTOPPED or RUNNINGになったらLambdaを実行するよう設定し、LambdaのロジックでECSのタスク情報から新たに立ち上がったサーバのIPを取得し、Route53の該当FQDNにIPを追加登録する処理を行っています（途中色々端折って書いています）。
デプロイで次に問題になってくるのが、電話中のお客様をどうするかというものです。
電話自動応答サービスという都合上、通話中のお客様のセッションをぶつ切りにすることはできず、一通りの通話を終えるまでセッションを維持する必要があります。
そのため、MOBI VOICEではBlue/Greenデプロイを採用しています。
Blue/Greenデプロイとは、新旧など2系統のサーバ群が同時に混在する環境を構築した後、ロードバランサー等によるルーティング制御によってトラフィックを切り替え、ダウンタイム無しで環境を切り替えることですが、このルーティング切り替えを上記Lambdaの機構で行っています。
デプロイ前のバージョンのサーバは一定期間稼働させたままにするため、通話中の電話はつながったままにし、新しいセッションは新しくデプロイしたサーバに送ることができます。
これにより、MOBI VOICEで無停止でのデプロイが可能になりました。
今後はPBX連携なども進めているため、より電話の通信環境パターンが増え、複雑になっていくことが予想されます。特に通信環境要件によってはIPレンジの固定化が必要だったり、特定IPに固定する必要が出てきたりすると思います。今のデプロイ方法だけでは対処できない可能性も出てくるため、環境ごとにより可用性が高く運用に支障のないデプロイ方法が必要になってきます。
今後も環境ごとに最善なデプロイ方法を模索していきたいと思います。
