Serverless Operations, inc

>_cd /works/id_396

title

新たな収益源として独自サービスの内製化を目指した地方局が求める「完全サーバーレス」の実現を支援

og:image

client

北海道テレビ放送株式会社

北海道テレビ放送(HTB)は
1968年に北海道初のUHF局として誕生した民間放送局です。
「水曜どうでしょう」を初めとしたバラエティ番組や、多くの受賞歴経験を持つニュース・ドキュメンタリー、そしてドラマなど、様々な分野の番組制作や放送を通して、「ユメミル、チカラ」を応援し、 地域の未来に貢献していきたいと考えています。

summary

  • 有料映像配信サービスとECとが融合したオリジナルサービスの開発支援をServerless Operationsが担当
  • 限られた人材で効率的な開発を行うために、サーバーレスのアーキテクチャが必要条件
  • RDBを使わずにAmazon DynamoDBの条件付き書き込みによってEC在庫の厳密な処理を実演

はじめに

北海道テレビ放送株式会社(以下、HTB)は、札幌に本拠地を置く北海道を対象とした放送局です。東京や大阪に拠点を置き全国で放送される番組を作るいわゆるキー局とはことなり、地域に向けた番組作りを行っていますが、そうした番組のひとつ「水曜どうでしょう」は徐々に人気を獲得し、今では全国的に知られるまでになりました。

同局の三浦一樹さんは、コンテンツビジネス局ネットデジタル事業部に所属し、同社のストリーミングサービスやECサイトの開発や運営を主導する立場。しかし、三浦さん自身もチームのメンバーもエンジニアではないため、サービス開発ではしばしば行き詰まることがありました。そこで開発支援をServerless Operationsに依頼した。その経緯を三浦さんと、Serverless Operationsの堀家さん金さんにうかがいました。

左上から時計回りで、Serverless Operations金さん、北海道テレビ三浦さん、ライター青山さん、Serverless Operations堀家さん

開発する上でサーバーレスが絶対条件のワケ

――HTBは放送局ですが、三浦さんはそこでどのようなサービスを提供されているんでしょうか。

三浦 コンテンツビジネス局のネットデジタル事業部というところに所属しておりまして、コンテンツビジネス局全体が放送外収入を支える事業部というイメージですね。放送局は企業などに広告枠を買っていただいて、CMを流すことが主な収益になるんですが、私の部署はそれ以外で収益を上げるところです。

例えば、弊社には「onちゃん」というオリジナルキャラクターがいるんですが、そのグッズを販売したり、「水曜どうでしょう」のグッズを売ったり、独自のVODサービスで弊社が製作した番組をストリーミング配信したり、他局が弊社のコンテンツを二次利用する時の権利処理とかをしています。そのなかで私は開発を担当しています。

――放送局で放送以外の仕事となると、とても幅広く手がけることになるんですね。今回、Serverless Operationsには開発支援を依頼したそうですが、どのようなシステム開発に取り組んでいたのですか。

三浦 「onライン劇場」という、有料での映像配信とグッズ販売のECとが一緒になったサービスです。2020年に新型コロナウイルス感染症の拡大によって、各種のオフラインイベントが潰れてしまったので、その代替施策として考えたものです。

もともと2019年に「水曜どうでしょう祭 FESTIVAL in SAPPORO2019」というオフラインのイベントを実施した際、一緒に有料での動画配信の仕組みを作っていたので、それを活用したかったんです。その動画配信の仕組みをテコ入れして、配信ページにShopifyの購入ボタンを貼り付けただけのような形で、最初のonライン劇場がスタートしました。

その当時、動画を見ながら関連グッズを買えるというサービスが見当たらなかったので、自分で作るしかないと思ったのが、アイデアのきっかけです。結果的にある程度、うまくいったので、社内を説得して開発費が出ることになり、不満だった部分を作り直すところから、Serverless Operationsに開発支援で入ってもらいました。

――なぜ、最終的にServerless Operationsを選んだんでしょうか。

三浦 最初のVODサービスの開発を依頼したところも含めて、いくつかの開発会社に相談をしていて、Serverless Operationsもそのひとつでした。もともと堀家さんとは、あるユーザー主体の勉強会で知り合いました。勉強会のライトニングトークで動画配信について話したら、その後の懇親会で堀家さんが声を掛けてくれて、それがとても印象に残っていたんです。

今回の開発にあたって大前提だったのは、サーバーレスで行うことでした。そのわけを私はよく冗談で「宗教上の理由で」といっていますが、それというのも我々の部署にはサーバーサイドエンジニアもネットワークエンジニアもいないんですね。だから、できるだけ開発するときは、コーディング以外のことをしたくないので、サーバーレスという条件は絶対的なものなんです。

私自身、HTBの入社当初は「放送監視」という、放送されている番組を一日中見るという仕事で、それまで開発経験はありませんでした。他のメンバーも電波塔で電源工事をしたり、壁の補修でモルタルを塗ったりと、まったくITとは無関係の経歴の人間ばかり。そういうメンバー達と一緒に、勉強しながら開発しているんです。

だから、できるだけ余計なことはしたくないのですが、開発会社に相談すると、ほとんどがサーバを立てることが前提なんですよね。僕らは、クラウドのなかには極力、なにも置きたくないのに、すぐにサーバを立てることが必要な提案をしてくる。まるでサーバーレスという要望がわがままなことかのように言われると、残念な気持ちになってしまいます。

そこで、AWSのパートナーになっている会社にもいくつか話を聞きましたが、フロントもバックエンドもできるところや、Auth0などの外部のAPI連携に詳しいところとなるとなかなかなくて、そういう区別無しに相談に乗ってくれたところはServerless Operationsだけだったんです。

冷や汗をかいた過剰販売を二度と起こさない

――Serverless Operationsは、具体的にどのような支援を行ったんですか。

 開発に当たって、いろいろな質問を受けて、それに対して回答するという形で支援しました。最初は不定期でしたが、途中からは週1回の定例会議を設定して、そこでまとめて受け付けるようになりました。

開発に関して一番、印象的だったのが、EC部分の在庫管理の仕組みのところですね。グッズの販売で在庫管理が上手くいかずに在庫数以上の販売を行ってしまうというトラブルに対して、DynamoDBの条件付き書き込みという機能を使って解決しました。

三浦 2020年の10月に、onライン劇場で「水曜どうでしょう」の福袋を限定販売したんですね。結果的に400個くらいが数分で売り切れて喜んでいたんですが、販売後にShopifyの管理画面を開いたら、在庫がゼロではなくてマイナス10になっていたんです。つまり、実際に在庫している数よりも10個も多く売ってしまっていたんです。

調べたら、Shopifyが標準で用意している決済方法なら問題ないはずが、JCBに対応するための別の決済方法を使ったのが原因でした。過剰販売分はキャンセルしてしまえば対応も簡単でしたが、お客さんが楽しみにしているからそれはしたくなかった。結局、あちこちにお願いして回って、なんとか商品が確保できましたが、めちゃくちゃ肝が冷えた出来事でした。

それで、ECでの発注処理のデータベースの更新処理も自分たちでコードを書くことにしたんですが、絶対に在庫がマイナスにならないようにするためにはどうしたらよいのか、いろいろやってもできなかったんです。

 そのタイミングで相談を受けて、僕も1週間くらい悩んで、DynamoDBの条件付き書き込みを使えば上手く行くことに気がつきました。DynamoDBの条件付き書き込みは、トランザクション処理ではなくて、単一レコードに対する排他制御です。DynamoDBにはそもそも楽観的排他制御っていう手法はあるんですが、いずれにしても結果整合にフォーカスした対応なので、今回のような在庫だと単一レコードに対する強い一貫性のある排他制御が必要です。

そこで、多少のパフォーマンスは犠牲にして、強い一貫性の書き込みモードを維持しつつ、在庫数をチェックしながら書き込みを行うということをしています。SQLが使えるリレーショナルデータベースなら簡単にできることなんですが、DynamoDBの本来の使い方からするとレアな機能です。ただ、古くからある機能なので、それを使ってサンプルコードも作成して上手く行きました。

蓄積したノウハウで将来は他の地方局の支援にも

――今回の要望をDynamoDBで実現するのは、そんなに珍しいなケースなんでしょうか

堀家 一般的にはリレーショナルデータベースを使った方が簡単にできます。ただし、AWSでリレーショナルデータベースを使うにはAmazon RDSというサービスになるんですが、これを利用するにはAWSのなかでネットワークの設定が必要になるので、考えることが一気に増えます。DynamoDBならネットワークのことを一切考えなくてよいですから、すべてサーバーレスで開発するなら、Amazon RDSの利用は躊躇します。結局、レイヤーの違うサービスなんですよね。

三浦 SQLなんてメンバーの誰も書いたことがないし、まずリレーショナルデータベース自体をよく知らない。DynamoDBのようにAPIのレスポンスだとイメージが付くんですけど、SQLだとよくわからないんですよ。

堀家 強力な整合性のある読み込みを行うケースは、リレーショナルデータベースであってもあまりない要件です。実際には、リレーショナルデータベースでも、リードレプリカが存在する場合に書き込みしたデータが全てのレプリカに完全に伝搬するのに少しの時差があるんですけど、そこの時差で困るケースってあまりないですから。

――ECでそこまでトラフィックが殺到したのは、「水曜どうでしょう」のような人気コンテンツだからですよね。

三浦 ただ、テレビ放送がきっかけになってウェブサーバーが落ちるということはよくある話で、TV業界は「スパイク」を見やすい業界と良く言われています。AWSの認定試験でも、「TVCMを受けてスパイクがたくさん来る場合はどうするか」という問題がよく出されます。

単純なコンテンツサーバーだけではなくて、ECの場合でもDynamoDBを使ったサーバーレスで構築できて、スパイクにも対応できるというのは、いざというときに切れるカードを持てるようになったので、すごく大きいことです。最終的には、TV局でのこうしたウェブ周りのシステムのノウハウをつかって、他の地方局をお手伝いできるようになれたらいいと思っています。

そのためにも、金さんのようなエンジニアの考え方や行動指針をもっと身につけて、最終的には誰にも頼らずに自社内だけで考えたり、作ったりできるようになっていければいいと思っています。まだまだ、金さんには頼ることが多いですが、すごく成長させていただいて、その目標に向けた大きな一歩を踏み出せたのはServerless Operationsのおかげです。

Back
to list
<-