システム利用者に押し付けないオペレショーンの自動化

どうもこんにちは。わんこ。です。

この記事は Twilio Advent Calendar 2017 の12/5の投稿となります。

システム利用者に押し付けないオペレショーンの自動化 とか偉そうなタイトルにしましたが、簡単に言うと架電によるサーバーのスケール対応の仕組みを作りました。というお話です。 何番煎じだよ!って感じなのですが、構築部分よりもプロセスに重きを感じていただければと思います。

番組連動コンテンツ

HAROiDはテレビ番組への参加型コンテンツのサーバーを構築/運用することが多いです。

番組放送時以外はアクセスは0ですが、放送開始(企画開始)と同時に全国に設置してあるテレビ端末から一斉に押し寄せます。急に数万rpsにもなるリクエストと、全くアクセスのない時間の区切りがはっきりしているのが特徴です。

もちろん番組放送の直前にサーバーをスケールアウトしていたのですが、嬉しいことにHAROiDのシステムを利用していただける番組が増えてきたため、一般的な業務時間外の放送も頻繁に発生していました。

なぜ必要なのか

いや、だって…朝6時とかにサーバーオペレーションが毎週発生するとか…(ヾノ・∀・`)ムリムリ スケジュールでスケールアウトもできるんですが、テレビ局さんでは前日の夜とかに急遽企画が決定することがあるので、全てをカバーすることはできません。

普段だって裁量労働制をいいことに12時頃にゆったり出勤しているエンジニアが半数以上を占めるHAROiDでは深夜はまだしも、早朝はなかなかにハードです。

元々HAROiDプラットフォームのシステム管理画面として、番組制作側にも操作できるサーバーの簡単スケールアウトの仕組みがあったのですが、放送作業中にPCなど触っている暇などない!(言い過ぎ)的な話も上がっておりました。

またテレビ局では本当に秒単位でのオペレーションを日頃から行っているため、放送時のコミュニケーションは電話が当たり前。そんな現場でした。

そりゃ現場で歩き回って、指示だして電話してー…の現場でPC出して慣れない管理画面からの操作なんて心理障壁も高いわなー。って

心理障壁を極力取り除こう

今までWebシステムなんだからWebの管理画面でなんとかしてよ。って思ってたんですけどこれって結局開発側のエゴなんだなって思いました。 利用するのは番組制作側であって、僕らと同業じゃない。っていう当たり前のことですね。

たしかにWebや、ネイティブアプリ等で提供すれば表現力もある、いろんなことができるツールをクライアントに提供することができます。 ですが、それって本当にクライアントが望んでることなのでしょうか。ということです。 もちろん、クライアントの課題を解決するために要求以上のものを提供して、クライアントに新たな気付きや価値を提供できることは素晴らしいことですが、そこだけを目指してしまうと微かなズレが更に乖離を生むことにもなりかねません。

極力彼らが普段から馴染んでいるツールで、尚且つミスの発生しにくい一方通行なオペレーション。分岐が発生すればするほど、更に心理障壁を生むことになります。

Twilioで実装

まぁ前置きはここまでとして、HAROiDの架電スケールアウトの仕組みですが至ってシンプルです。

Phone→Twilio→Api Gateway→Lambda→管理システムAPIの流れです。
社内ではてる助と呼んでいます。 てる助

  1. 番組制作側からTwilioで取得した電話番号に架電
  2. 事前に共有しておいた番組コードを入力
  3. 該当番組サーバーのステータスを確認して、放送用にスケールアウトするかの確認
  4. スケールアウトが開始されたら通話を終了
  5. スケールアウト完了の通知がWebhookにてAPI Gateway&Lambdaに通知
  6. スケールアウト実施の結果内容を架電及び、SMSで通知

という流れになります。

INCOMING の設定について

まず最初に取得した電話番号に着電があった際に起動するTwiMLAppを定義します。 TwiMLApp

  • RequestURLにははじめの着電の際にコールされるAPI
  • フォールバックURLには何かしらのエラーが発生した際にコールされるAPI
  • StatusURLには通話終了などのイベント発生時にコールされるAPI

を設定します

INCOMING 次に電話番号に対しての設定で上記のように設定し、先程作成したTwiMLAppを設定します。

DynamoDBについて

この中でDynamoDBを使っているのは、通話という非常に長いトランザクションかつ、単一リクエストが担保されていないインターフェイスを利用しているので排他制御のためステート管理の役割を持たせるためです。

SMSの送信について

残念ながら、Twilioでは通常取得する050番号でのSMSの送信ができません。

よって、アメリカの電話番号を別に取得する必要があります。

試行錯誤してみて

  • 思ったよりも日本語を綺麗に喋ってくれる
  • #イゲタ(井桁) と電話システムらしい解釈で発音される
  • 0レイ と発音されるので ゼロ と入力してあげると幸せになれそう
  • Pause(発音間)は指定できるけど、あまり精度がよくなさそう?前後の母音の有無によって0.3~0.5secほどズレてるように思う(要検証

誰かTwilioの日本語をうまく喋らせる変換ライブラリとか作ってください。お願いします。

まとめ

今回はTwilioの実装としてはよくある架電からのAPIコールという流れで実装してみましたが、大規模なスケールアウトを一般的な業務時間外であっても、Webシステム等に距離を感じてしまっている現場の方でも安心してオペレーション出来る取り組みの一つとして考えてみました。

テレビの現場以外でも、Webシステムに抵抗を感じている現場の方たちも一定います。 私達の作ったWebシステムを納品しているからといって、その現場で誰しもがWeb操作をできる状況や慣れ親しんでいる保証は一切ありません。むしろないです。

自分達が考える 便利 と利用者における 便利 & 安心/安全 は全く別の軸である場合も考えて設計をするべきだと思いました。

Wanted

利用者のことを考えつつ、自分達の運用負荷を減らしてビール飲んだりするのが好きなエンジニアの方、興味を持っていただければ、遊びに来ていただいたり、お話したりだけでも大歓迎ですので是非よろしくお願いいたします。

YourCast - Wantedly