はじめに
前回までで、MilkcocoaのJavaScript SDK、Node.js SDK、iOS SDKの紹介をしてきました。今回は株式会社LIGで実際の案件でMilkcocoaを利用した事例を紹介したいと思います。
Milkcocoaを使ってどんなことが出来るのか、イメージする手助けになれば幸いです。
リアル連動型のクリスマスキャンペーン企画の裏側を支えたMilkcocoa
2014年12月にLIGとSHIFTBRAINでクリスマスのキャンペーン企画を実施しました。それに伴い、特設サイト(SANTA CLOSE TO YOU)の制作を行いましたが、裏側でMilkcocoaが大活躍してくれたと言う事例です。
クリスマスに働くオトナにわくわくを届けた企画
クリスマス当日は仕事でクリスマスどころじゃない。そう言った「いそがしいオトナの、あなたのもとに。」わくわくを届けると言うのが今回の企画のコンセプトでした。
Twitterでハッシュタグ付きのツイートをしてくれた人に、クリスマス当日にサンタが実際にプレゼントを届けに行くという内容です。また、プレゼントが届いた人にはサンタと一緒に写真を撮ってTwitterに投稿してもらいました。
サンタの現在地を表示する位置情報やTwitter、ツイキャスによる動画配信を使い、実際にサンタが街を歩き回っている様子をリアルタイムに演出しました。
企画の詳細や実施報告はLIGのまとめ記事を見ていただきたいです。
時間とリソースがない中での実装
12月の頭に構想を決めて、12月18日にはティザーサイトの公開、実施は12月25日(木)。と言うタイトなスケジュールでした。尚且つ、バックエンドエンジニアは1名(筆者)で実装しました。
Webサイト側の実装以外を全てやる必要があり、作業範囲が割と広い印象でした。
主な作業領域は以下になります。
- 全体アーキテクチャ設計
- インフラ設計
- サーバ側ロジック実装(Tweet取得やNGワードフィルタ等)
- リアルタイム通信系の処理実装
- 当日オペレータ用の管理ツール実装
- サンタの位置情報発信ツール実装
- ティザーサイトロジック実装(Tweet取得等)
- Twitterや動画配信用のアカウントやSDK手配
その他にも、細かい作業を色々としました。
このように、作業者が少ないと実装以外の部分もエンジアが担当しないといけない場面はよくあると思います。
Milkcocoaで負荷分散
人数と時間が限られる中で、アクセス集中時の負荷分散をMilkcocoaを利用することでほぼ考えなくて済みました。
キャンペーンは実際のアクセス数などが予測しづらい
企画の構想段階では、AWS上でインフラ構築を検討していましたが、ティザー公開時や当日にどれくらいのユーザがアクセスしに来るのか予想がしづらい状況でした。特に当時のLIGではそういった性質の案件を行った経験が無く、アクセス数の予測を綿密に立てて、スケールアウトを考慮したインフラ設計をするためには時間が足り無いだろうと感じていました。
静的サイトはMilkcocoaとS3
どのようなサービスでもシステムダウンは避けたいところですが、このようなアクセス数が想定出来ないサービスやキャンペーンのように公開時間が短い場合は対応が難しいです。最近だと、HTML/CSS/JavaScriptなどのデータは静的サイトとして生成しておき、AWS Amazon S3(以下、S3)上にホスティングしてしまうのが、コストパフォーマンスが良いとされます。S3は99.999999999%の堅牢性と、99.99%の可用性を誇るらしく、ほぼ落ちないと言っても良いと思います。
S3上に設置した静的サイトに関しても、Milkcocoaを使うことで簡単にリアルタイム通信やデータ保存と言った機能を追加することができるのがMilkcocoaやBaaSの良いところだと思います。この枠組みは、案件の制約上、サーバサイドプログラムが使えない場合でも活きてくると思います。
Milkcocoaを仲介することで負荷分散を試みた
Milkcocoaを使わずに検討した当初の想定では、S3に静的サイトを載せ、AWS Amazon EC2(以下、EC2)インスタンスを2つ用意し、片方にはNode.jsとSocket.ioによるリアルタイム通信用+データアクセスのサーバ機能を持たせ、もう片方にはMongoDBを載せると言った構成でした。
この構成の場合S3は落ちることはほぼ無いですが、S3へのアクセス数に合わせてEC2へのWebsocketコネクション数が上がって行き、負荷が高くなって行きます。更にTwitterAPIやGPSの情報もリアルタイムにMongoDBへ保存しつつS3へデータを送ると言った処理もあるため、EC2にアクセスが集中してしまいます。
これに対して、今回の場合は、EC2とS3の中間にMilkcocoaを挟むことで対応しました。データベース機能、Socket.io機能を肩代わりしてくれ、S3へのアクセス数はMilkcocoaが吸収してくれたため、EC2への負荷を軽減することができました。
これにより、EC2は安心して一番安いプランで運用を行い、EC2インスタンスも1つにすることができ、費用面をかなり削減することができました。また、Socket.ioやMongoDBの準備をする必要が無くなったため、作業工数を抑えることも可能となりました。
今回のサイトではサーバ側で取得したTweetやGPSの情報をクライアント側へリアルタイムにプッシュすると言うデータの流れで、クライアント側はデータへのアクセスだけだったため、この仕組みを効果的に扱うことが出来ました。
例えば、クライアント側からサイト上に情報を投稿して、それをサーバ側で処理するような仕組みのサービスの場合は、投稿数に比例してサーバ側へのアクセス数も増えるのでまた別の構成を考える必要があると思います。
向き不向きはあると思いますが、構築するサービス・アプリケーションのタイプによっては、このようにMilkcocoaが負荷分散に大きく役立ってくれます。読者の皆さんも是非参考にしてみてください。
LIG社内の受付システムで活躍するMilkcocoa
IoT領域の事例でもMilkcocoaが活躍してくれました。LIGで社内受付システムを作ったときにデバイス連携を行いましたが、その裏側にMilkcocoaを採用しています。
受付システム構築の背景
LIGにはお客さんが良く来ます。仕事の依頼、面接、出前と様々です。大抵の会社は受付やそれに近い仕組みがあるものですが、LIGはまだそう言ったものが整っていません。会社に来た人は入り口で待ちぼうけ、どうすれば良いのか迷ってたたずんでいることがあります。入り口に呼び出し用の内線電話は置いてあるのですが、電話の存在に気付かない人が多いです。社員の誰かがお客さんの存在に気付いたら案内する、と言うなんともアナログな状態でした。私が面接で初めてLIGに来たときも、どうすれば良いのか分からず戸惑った経験がありました。
Romoを使った社内受付システム
そこで、社員のメンバー一覧を表示するWebサイトを作っておき、iPadに表示できるものを作りました。お客さんが社員をタップすることで、社内のチャットツールや社内スピーカーに通知をする仕組みを作り、改善を務めています。社員に通知が行き、お客さんが待機している状態のときにRomoというラジコンロボットを動かしておくことで、お客さんが待ち時間にストレスを感じないような工夫をしました。
このシステムはRomotive Japan のブログにも紹介されています。本記事はMilkcocoaの視点で執筆していますが、Romotive Japanのブログの記事ではRomo視点で書かれています。
RomoとWebの連携はMilkcocoa iOS SDK
実はRomoはiPhoneとiOSアプリケーションで動作し、SDKが公開されています。そのため、Milkcocoa iOS SDKと組み合わせることで、簡単に受付システムのWebサイトとRomoをつなげることが出来ました。
iOS開発はSwiftを利用していますが、裏側はNode.js、表側は静的サイトということで、これら全ての環境で同じ使い勝手で連携部分のロジックが書けるので、実装時間の短縮をすることができ、UI部分やコミュニケーション設計と言った別の要素に時間を掛けることができました。
まとめ
今回はLIGで実案件でMilkcocoaを使った事例の紹介をしました。クリスマスサイトでは負荷分散や作業工数削減、社内受付システムではIoT領域での活用と言うことで、それぞれ実装する中でMilkcocoaの恩恵をすごく感じました。
今回言いたかったことをまとめると以下になります。
- 時間が無い中で作らないといけない場合
- エンジニアの数が圧倒的に足りない状態で作らないといけない場合
- リアルタイム通信を簡単に行いたい場合
- コストを抑えてキャンペーンなどを行いたい場合
- IoT制作でデバイスとWeb、デバイスとデバイスを簡単に連携させたい場合
- Webサービス等のプロトタイピングをサクッと行いたい場合
こう言った場合はMilkcocoaはすごくオススメだと思います。
前回までに紹介してきた内容はMilkcocoa SDKのツールとしての使い方の紹介だったため、具体的な利用イメージが掴みづらかったかもしれません。今回の記事をご覧になり、Milkcocoaが実際に皆さんが関わるプロジェクトで使うイメージが湧き、実際に使われることになれば幸いです。