クラウドを使ってみて、思うような効果を得られず「がっかり」するユーザーは少なくない。サービスが未成熟だったり、利用上の制約があったり、原因は様々だ。クラウド活用に苦戦した経験を持つユーザーの事例から、トラブル脱出の勘所を探ろう。

 クラウド活用では思わぬトラブルに遭遇するケースが少なくない。性能やコストの考え方にはクラウドならではの特徴がある。オンプレミス(自社所有)環境の常識が通じないところもあるので、課金体系などをよく調べておきたい。

 クラウドでは次々と新サービスが登場するが、その成熟度の見極めも欠かせない。サービスの中には、リリース最優先でユーザーへの提供を開始し、そこから改善を繰り返すものもあるからだ。

 AWS(Amazon Web Services)やMicrosoft Azure、GCP(Google Cloud Platform)といったメガクラウドでは、新たなサービスや機能のリリースは米国で先行する。日本での提供が遅れるため、使いたいものがある場合は、暫定運用しながらリリースに備えることも考えたい。

 クラウド活用でトラブルに遭遇しながらも、工夫で乗り越えたユーザー事例を見よう。

性能が自動で上がらない 負荷テストで最適化

 朝日放送テレビは、お笑い番組「M-1グランプリ」の魅力向上を狙いAWS上に敗者復活戦投票システムを構築した。クラウドを使ったのは「オンプレミス環境では膨大なアクセスに対処できないからだ」と、開発を担当した、デジアサ デジタルコンテンツ部門 小南英司氏(開発当時の所属は朝日放送 技術局 開発部)は話す。

 このシステムは、視聴者投票によって敗者復活のメンバーを決めるためのもので、番組放送中に大量のアクセスが押し寄せる事態が見込まれた。

 いくつかの構成案を検討した上で、最終的に「Amazon Kinesis Data Streams」を使うことにした。次々と発生するデータ(ストリームデータ)の処理に特化したサービスで、AWSのサービスの中では投票数をリアルタイムに集計するのに最も向いている。

 ところが、このサービスには思わぬ落とし穴があった。「Kinesisは指定を超える負荷がかかると自動的に性能を増強するオートスケールの仕組みがなく、投票データを取りこぼす懸念があった」(小南氏)。

 Kinesisは「シャード」と呼ぶ単位でデータ処理のスループット(単位時間当たりの処理件数)を管理する。ユーザーは必要なシャード数を指定してリソースを確保する必要がある。シャードの数を増やせばスループットは上がるが、使われないリソースはムダになる。

 小南氏らは、番組当日のアクセス数を予測し、負荷テストによってシャード数を精緻に見積もることで課題を乗り越えた(図1)。

図1●負荷試験を通じてリソースを最適化した朝日放送テレビ
*朝日放送の資料を基に本誌が作成
[画像のクリックで拡大表示]

 ピークの負荷は秒間2万件、総得票数は20万件を予測値とした。番組中にシステムが停止することは許されないので、Kinesisの性能に余裕を持たせて、予測値の1.5~2倍程度(秒間3万~4万件)の負荷に耐えられるように設計。オープンソースの負荷テストツール「JMeter」によって秒間1万件までの負荷を発生させた結果を基に精緻にシャード数を見積もり、40に決めた。

 番組放送当日は予測通り、20万1862件のアクセスがあった。大半のアクセスは、番組内で投票の告知をした直後の数分間に発生したが、安定運用を実現できた。結果として問題は無かったが、もし想定を大幅に超えるアクセスがあったなら安定運用できた保証はない。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が2020年1月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら