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

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

この記事は 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の流れです。社内ではてる助と呼んでいます。

f:id:tt-utsumi:20200707145800p:plain — てる助

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

という流れになります。