LINEメッセージ一斉配信が生む秒間1000アクセスサーバーレスで実現した運用ゼロのスケーリング

LINEメッセージ一斉配信が生む 秒間1000アクセス サーバーレス で実現した 運用ゼロ のスケーリング ユニークビジョン株式会社 CTO 青柳康平 Copyright ©Unique Vision Company. All Rights Reserved. 1

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 2

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 3

01. イントロダクション 会社紹介 / 自己紹介 ユニークビジョン株式会社 SNSマーケティングの領域でキャンペーンの実施や SNSアカウントを管理するツールなどを提供する会社 取締役CTO 青柳康平 2026年4月時点で全社員79人、エンジニア36人 エンジニアは自社ツールの開発、キャンペーンの 案件開発を行っています。 主に開発をしながら、全社の技術方針や開 発方針を取りまとめている いわゆるプレイングマネージャー キャンペーン実施件数 600 バックエンド開発とDB設計が得意 件以上/年 Copyright ©Unique Vision Company. All Rights Reserved. 4

01. イントロダクション SNSキャンペーン ユニークビジョンでは 様々なSNSプラットフォーム上でキャンペーンを行えるシステムを提供しています。 それぞれのキャンペーンはプラットフォームごとにマッチした機能を提供しています。 ● 𝕏 ● LINE ● TikTok ● Instagram ここでは、 LINEキャンペーン についてお話します。 Copyright ©Unique Vision Company. All Rights Reserved. 5

01. イントロダクション LINEキャンペーンとは？ LINE からアクセスされることを想定した Webページで行われる様々なキャンペーンのことを言います。 例 ● レシートをアップロードしてポイントを取得 → ポイントで懸賞に応募 ● 簡単なゲームをして得点を競う ● 動画を視聴して最後まで見たらLINEポイントがもらえる Copyright ©Unique Vision Company. All Rights Reserved. 6

01. イントロダクション LINEキャンペーンの例 「レシート画像」を参加条件とした マストバイ型のキャンペーンとなります。 お客様がお買い上げいただいたスーパー・コンビニなどの購入レシート画像を Webページでアップロードすると、キャンペーンに応募ができます。 アップロードされたレシート画像は、外部のOCRサービスにて解析処理を実行し、条件を満たした場合に 即時 または 事後 に当落結果を通知します。 撮影 応募サイト 友だち追加 画像アップロード 抽選結果 対象商品を購入した レシートを撮影 キャンペーンアカウントのリッチ メニュー等から応募 LINE認証で友だち追加を 許可（初回のみ） 撮影した画像をアップロードして 応募完了 レシート画像を判定して即時、 または事後に結果を表示・通知 Copyright ©Unique Vision Company. All Rights Reserved. 7

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 8

02. LINEメッセージ一斉配信がもたらす突発負荷 広告配信 キャンペーンを行うにはユーザーにキャンペーンが始まることを告知する必要があります。 そのために広告出稿が行われます。 広告の例 ● テレビCM ● 電車の中吊り広告 ● Webへの広告 Copyright ©Unique Vision Company. All Rights Reserved. 9

02. LINEメッセージ一斉配信がもたらす突発負荷 広告からサイト流入までのステップ ユーザーの状態 広告が視界に入る 内容を確認・理解する アクセスへの準備動作 手を止める・見入る 「自分に関係あるか」の判断 QRのスキャン、キーワード検索 リンクのクリック 偶然その場に 居合わせる人 広告に意識を 向けている人 内容に興味を 持っている人 サイトを閲覧する サイトに アクセスした人 キャンペーンサイトにアクセスするまでにいくつかの障壁があるため、 大量 に同時アクセス してくるようなことは無い 。 Copyright ©Unique Vision Company. All Rights Reserved. 10

02. LINEメッセージ一斉配信がもたらす突発負荷 LINEメッセージ一斉配信 LINEキャンペーンでは既に友達になっているユーザーにメッセージを送信することで キャンペーンの開始を知らせることができます。 LINEのPush通知はほぼ全員に届くので、 キャンペーンサイトのアクセス数は瞬間的に増大します。 LINEからプッシュ通知が届く 通知をタップ キャンペーンサイト 通知をONに している人 内容に興味を 持っている人 サイトに アクセスした人 ユーザーの状態 容易な操作 でサイトにアクセスできるので瞬間的にアクセス数が増大 Copyright ©Unique Vision Company. All Rights Reserved. 11

02. LINEメッセージ一斉配信がもたらす突発負荷 計画的な一斉配信の場合 負荷の規模 ● 友達数：3千6百万人 ● 実際に配信する数：1百万 人（さすがに一気に全員はしない） ● 結果：秒間1000 アクセス超 通常時のアクセスと一斉配信があるときのアクセスは比較にならないほど違いがあります。 そのため、あらかじめ一斉配信するスケジュールを確認 して、サーバーを増強 して待ち受けます。 Copyright ©Unique Vision Company. All Rights Reserved. 12

02. LINEメッセージ一斉配信がもたらす突発負荷 予測不可能なタイミングでの一斉配信の場合 ● お客様側で簡単に実行可能なため、事前連絡がないケースがある ● 監視アラームで初めて検知し、慌ててサーバー増強 ● イレギュラーなリカバリー対応はエンジニアが必要 顧客が一斉配信 事前通知無し ユーザーが 一斉にアクセス サーバーに 負荷がかかる アラートを検知 サーバーを増強 リカバリー対応 通常の アクセス体制 運用担当者に 通知が届く 運用担当者が 急ぎ対応 エンジニアが 対応 Copyright ©Unique Vision Company. All Rights Reserved. 13

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 14

03. リアーキテクチャ前の課題 システム構成 主な構成は次の2つになります。 ● ● Amazon ECS (Web/常駐プロセス) Amazon ElastiCache Redis (セッション/ストレージ) 大量にアクセスがあっても耐えられる構成 にしています Copyright ©Unique Vision Company. All Rights Reserved. 15

03. リアーキテクチャ前の課題 AmazonECS ECSはコンテナ化されたアプリケーションを簡単にデプロイできる仕組み ● ● ● ● Webサーバーや常駐プロセスなど常に動き続けるプロセスを配置 起動するプロセス数をコントーロール可能 プロセスがダウンしても自動で復旧 ECSの前にロードバランサー配置して大量アクセスに対応可能 Copyright ©Unique Vision Company. All Rights Reserved. 16

03. リアーキテクチャ前の課題 ElastiCache for Redis Redisはシングルスレッドで動作するメモリDB ● ● ● ● ● バックエンドのストレージとして利用 シングルスレッドなので同時アクセス制御が容易 RDBでは耐えられない負荷にも対応可能 大量のメモリを利用するためにサーバースペックを上げる必要がある 高いサーバースペックのため、コストも高くなる Copyright ©Unique Vision Company. All Rights Reserved. 17

03. リアーキテクチャ前の課題 事前スケーリング作業 一斉配信前に運用担当者は次の設定をします。 ● ● ECSのサーバー台数の増加 Redisのサーバースペックのアップ ECSにはオートスケールという手段もありますが、あまりにも急激に負荷がくるため、 オートスケールでは間に合いません。 スペックアップ 増加 Copyright ©Unique Vision Company. All Rights Reserved. 18

03. リアーキテクチャ前の課題 課題 このアーキテクチャでは以下のような課題がありました ● 一斉配信ごとに運用者が手動でサーバー増強対応 ● 突然の一斉配信でアラート対応 ○ サーバーの増強 ○ リカバリー処理 ● 一斉配信が終わった後でサーバー数の削減を忘れて無駄なコスト発生 Copyright ©Unique Vision Company. All Rights Reserved. 19

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 20

04. リアーキテクチャ 方針検討 このままでは、規模を大きくしていくことの限界を感じていたので、全面刷新としてリアーキテクチャを決断 しました。以下を解決するために、ゼロベースで検討することになりました。 ● 人の作業を極力無くす ● 今までと同じように大量のアクセスに対応 できる ● 突発的な負荷に耐えられる ようにする ● インフラコストはできれば下げたい Copyright ©Unique Vision Company. All Rights Reserved. 21

04. リアーキテクチャ 方針 解決策：サーバーレス構成 への移行 ● ● ECS → AWS Lambda Redis → Amazon DynamoDB Copyright ©Unique Vision Company. All Rights Reserved. 22

04. リアーキテクチャ AWS Lambda ● ● ● イベント駆動：リクエスト時のみ実行 自動スケール：負荷に合わせて高速スケール 従量課金：常駐コストゼロ 苦労したこと ● IPv4に対応する必要があり VPCやNATゲートウェイなどが 必要になった ● 同時実行数制限 があるので、 制限緩和が必要 Copyright ©Unique Vision Company. All Rights Reserved. 23

04. リアーキテクチャ Amazon DynamoDB ● ● ● サーバーレスNoSQL：ミリ秒レイテンシ オンデマンドモード：スケール設定不要 高負荷対応：条件付き書き込み・強い整合性読み込み 苦労したこと ● Redisはシングルスレッドなのでデータ の整合性をとるのが容易。 しかし、DynamoDBは分散DB なので高 負荷対応の技 を駆使する必要 Copyright ©Unique Vision Company. All Rights Reserved. 24

04. リアーキテクチャ Amazon DynamoDB 条件付き書き込み ● 同じキーのレコードを書き込む場合、 先勝ちにして、後から書き込みは失敗さたい ● 条件付き書き込みは、条件が成り立つ場合にのみ書き込みが成功する機能 ● 例えば最終更新日時を読み込んでから、最終更新日が一致している場合のみ更新 す ることで整合性がとれる Copyright ©Unique Vision Company. All Rights Reserved. 25

04. リアーキテクチャ Amazon DynamoDB 強い整合性読み込み ● 結果整合性 ○ DynamoDBでは書き込み直後に読み込んでいても反映されない ○ 最終的には値が反映される ○ これは複数のサーバーで同期を取るのに時間がかかるため ○ しかし在庫の数など必ず正しい値が必要な時に問題 ● 強い整合性読み込み ○ 読み込み時に強い整合性を指定すると反映された値が取得できる ○ ただしコストが倍になる ○ 必要な場所だけ限定して利用した Copyright ©Unique Vision Company. All Rights Reserved. 26

目次 01. イントロダクション 02. LINEメッセージ一斉配信がもたらす突発負荷 03. リアーキテクチャ前の課題 04. リアーキテクチャ 05. 成果 Copyright ©Unique Vision Company. All Rights Reserved. 27

05. 成果 スケーリング運用ゼロの実現 ● 事前準備・後片付けが完全に不要に ● 無連絡の一斉配信にも自動で対応 ● リカバリーも発生しなくなり、その稼働も無くなった 突発作業 後片付け サーバーレス 全て不要になった！ リカバリー対応 事前準備 Copyright ©Unique Vision Company. All Rights Reserved. 28

05. 成果 コスト最適化 ● アクセス量に完全連動した課金体系 ○ ○ ● 以前では事前に一斉配信が起こる前にサーバースペックを増強して、 来るまでの間必要の無いコストが発生していた 以前では一斉配信後でサーバースペックをダウンしていたが、 遅れたり忘れたりすると必要な無いコストが発生していた データ量に応じた料金体系 ○ ○ Redisでは保存できるサイズを増やすのにサーバースペックを上げる必要があり ベースのコストが高かった DynamoDBでは使用した分だけコストが発生するので余計なコストが無い 固定費 従量課金 Copyright ©Unique Vision Company. All Rights Reserved. 29

05. 成果 まとめ リアーキテクチャ前の課題がどうなったのか？ ● 一斉配信ごとに運用者がサーバー増強対応 → 運用工数ゼロ ● 突然の一斉配信でアラート対応 → オートスケール機能で対応可能 ● 一斉配信が終わった後でサーバー数の削減を忘れて無駄なコスト発生 → 従量課金なので発生しない 課題では無かったが、データ保存のコストも大幅に下がった Copyright ©Unique Vision Company. All Rights Reserved. 30

05. 成果 学び ● 「運用工数」に絞った課題定義 → 現在の問題を解決するために、必要なものをゼロベースで検討 ● 突発負荷にはサーバーレスが良い → ECSのオートスケールでは間に合わないが、 Lambdaは高速で立ち上がるので対応可能 ● 適材適所のアーキテクチャ選択 → 技術的に難しいこともあるが、解決できれば成果に繋がる Copyright ©Unique Vision Company. All Rights Reserved. 31

ご清聴ありがとうございました！ Copyright ©Unique Vision Company. All Rights Reserved. 32