ユーザー体験を落とさずS3のデータを8割削減した工夫（キムさん）
VCNCという会社でデータ分析などをしているエンジニアのキム・ミョンホさんは、グローバルで1700万ものダウンロードを実現しているカップル向けのSNS「Between」を担当している。
カップル向けSNS「Between」を手がけるVCNCのエンジニア キム・ミョンホさん
カップル同士で写真や動画を共有できるBetweenでは、写真がきわめて重要だという。写真はアップロードされた段階で、さまざまなデバイス向けのサムネイルが生成され、S3に保管される。これをCDN経由でユーザー側のBetweenアプリに配信するのが一連の流れだという。しかし、こうした仕様のため、写真の枚数とサイズが膨大になる。オリジナルの写真だけで11億枚（！）、サムネイルまであわせて66億枚、そして総計で738TBというデータ量に膨らんでいるという。これに対して、キムさんは「貧乏なスタートアップなので、費用は削減しなければならなかった」と述べ、データの削減プロジェクトに着手したという。
デバイスや画面サイズごとにサムネイルを生成していた
まずやったのはデータの利用形態を調べること。Betweenはサービスの仕様上、写真がカップルにしか共有されないため、デバイスの数が限られる。つまり、ユーザーが持っていないデバイス向けのサムネイルは無駄になるわけだ。また、写真もアップロード後に30日を過ぎると、1/3程度しか参照されない。そこで、デバイスのリクエスト時にダイナミックにサムネイルが生成されるようにシステムを変更することにしたという。
これを実現すべく、VCNCではリサイズサーバーを追加した新システムを構築。グラフィックライブラリをCPU負荷の小さい「SKIA」（Google）に変更し、リサイズの速度を4倍くらい速めたという。また、S3に保管されているオリジナル写真は「WebP」（Google）というライブラリで品質を保ちながら圧縮することにした。
既存の写真を新システムにマイグレーションするにあたっては、「カップルの大切な思い出が詰まっている写真なので、1枚も失ってはいけない」（キムさん）ということで、細心の注意を払ったという。
古いアーキテクチャから新しいアーキテクチャへ
変換作業はSQSにデータを載せ、オートスケールでワークプロセスを立ち上げ、処理済みのデータはS3に保存。この間のマイグレーション作業のログや元データの削除ログもすべてデータベースに登録した。また、変換処理がきちんと継続するようCloudWatchを使ってスポットインスタンスを立ち上げ、オートスケールさせた。最大で140台のスポットインスタンスを立ち上げ、インスタンスの処理時間で考えると6676時間かかったという非常にヘビーな作業だったようだ。
コストのかかったマイグレーションだが、移行後はS3に格納するオブジェクト数がなんと8割以上削減された。また、サムネイルが不要になったほか、オリジナルデータも圧縮されているため、データ量も738TBからなんと184TBにまで削減できたという。コスト面でも従来に比べて68％削減されており、導入効果は大きかった。
高い圧縮効果でオブジェクト数やデータ量は大幅に削減
企画から移行完了まで約1ヶ月という短期間で実現し、クラウドならではのメリットを享受したようだ。キムさんは「ユーザー体験を保ったまま、オートスケールやスポットインスタンスをうまく使うことで、コスト削減ができた」とアピールし、セッションを締めた。
リアルタイム分析にサーバーレスアーキテクチャ採用（チョンさん）
韓国側の最後の登壇はチョン・ミニョンさん。AWSKRUGのファウンダーでもあるチョンさんは、無料のインターネットラジオを配信するBeat CompanyのCTOを務めている。今回は効率的な広告配信に必要なリアルタイム分析について説明した。
AWSKRUGのファウンダーでもあるチョン・ミニョンさん（Beat Company）
チョンさんが広告配信の分析で求める「リアルタイム」とは従来の日、時間、分の単位ではなく、秒単位を意味するという。「完璧な結果ではなくとも、ある程度誤差があっても、それをトレードオフとして、遅延を少なくするアーキテクチャが必要」（チョンさん）。これに必要なのが、Lambdaを活用したサーバーレスアーキテクチャだったという。
チョンさんが同社がサーバーレスアーキテクチャを採用した理由を、「必要な時に必要な分、柔軟に対応できること。デプロイやスケーリング、キャパシティ、耐障害性に関してもメリットがある。単純な処理を確実に処理できるアーキテクチャ」と語る。サービスを分割してシンプルにすることで、開発速度も上げられるし、品質も向上できる。「価値を生むコード以外を考えなくてもよいのが一番メリット」と考え、実際にAWS Lambdaを使ってみたという。
チョンさんはシステムの構成を明らかにしながら、説明を続ける。配信ユーザーのリクエストはまずAPI GatewayとLambdaを経由し、Kinesisに渡される。Kinesisには異なるイベントソースを付いており、これらをトリガにそれぞれ別のLambdaに渡される。1つは分析のためにElastic Searchに渡すLambda、もう1つはデータの再利用のためにS3に渡すLambdaだ。こうしたLambdaの活用で、ピーク時には1000リクエスト／秒を処理し、1日の平均で約300リクエスト／秒をさばくことができるという。
チョンさんは「API GatewayやLambda、Elastic Searchなどを含んでも、大型のEC2のインスタンスよりはかなり低価格で運用できる」と語る。また、S3に保存した特定のデータを任意に呼び出して、アドホック的に分析することも可能。とはいえ、「Lambda自体がまだ未成熟だったため、開発で苦労する点も多かった」と振り返る。
KinesisやLambdaなどのサービス概要についても丁寧に説明したチョン氏は、最後にElasticSearchの結果をkibanaのダッシュボードでチェックするデモを披露。リアルタイム性が高いので、時間帯別、分単位でユニークなユーザーを調べることも可能だという。
ElasticSearchの結果をkibanaのダッシュボードから見るデモ
