Sansanがメッセージング (SQS) でスケーラビリティを手に入れた話

Slide 1

Slide 1 text

Sansanがメッセージング (SQS) でスケーラビリティを手に入れた話 using C# on Windows; 神原淳史 @atsukanrock 2017-05-31 AWS Dev Day Tokyo 2017

Slide 2

Slide 2 text

自己紹介 • 神原淳史 @atsukanrock • Development Manager at • Interested in • Domain-Driven Design • C# / .NET • Enterprise Integration Patterns

Slide 3

Slide 3 text

目次 • Sansanサービスの説明 • メッセージングとは • メッセージングによる課題解決の実例 • メッセージングの注意点 • まとめ

Slide 4

Slide 4 text

Sansanサービスの説明名刺を企業の資産に変える

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

サービス全体像 Scanner データ化サービス (Digitization Service) 精度99% 社内の別組織が開発・運用 API Call Callback API API Call

Slide 7

Slide 7 text

マルチテナント型クラウドサービス tenant_id biz_card_id given_name family_name email … xxx 11111 太郎山田 … … xxx 22222 二郎鈴木 … … xxx 33333 三郎佐藤 … … xxx 44444 四郎田中 … … yyy 55555 五郎高橋 … … yyy 66666 六郎山本 … … yyy 77777 花子中村 … … テナント (≒組織) 内でデータ共有 DBテーブルをテナント毎に分割

Slide 8

Slide 8 text

サービス規模の拡大 2014 2015 2016 2017 Tenants 2014 2015 2016 2017 Users 2014 2015 2016 2017 Biz Cards 2014 2015 2016 2017 Maximum Users Per Tenant 2014 2015 2016 2017 Maximum Biz Cards Per Tenant スケーラビリティの課題が次々に発生

Slide 9

Slide 9 text

メッセージングとは前提知識を早巡り

Slide 10

Slide 10 text

メッセージングとは Message Queue Web App Web API Batch Message Consumer Server Message Message Message Message Database メッセージキューを介し、プロセス間やアプリケーション間でデータや制御を伝達する

Slide 11

Slide 11 text

特徴 • メッセージは単なるテキスト • 処理失敗したメッセージはリトライされる • 厳密には、再度処理対象となる • 一定回数失敗し続けたメッセージは別キューに退避される (Dead Letter Queue)

Slide 12

Slide 12 text

ミドルウェア Amazon SQS Standard Queue Amazon SQS FIFO Queue Azure Storage Azure Service Bus MSMQ PaaS Yes Yes Yes Yes No Transaction No No No Local Distributed At-most-once No Yes No Yes Yes FIFO Best effort Yes Best effort Yes (w/ session) Yes 現Sansanで採用

Slide 13

Slide 13 text

メッセージングによる課題解決の実例スケーラビリティを手に入れる

Slide 14

Slide 14 text

抱えていた課題 • 巨大なトランザクション • 終わらないバッチ処理 • 急激に変化するデータベース負荷 • 低いメンテナンス自由度 • リカバリ不可能な処理

Slide 15

Slide 15 text

Slide 16

Slide 16 text

巨大なトランザクション所有名刺の参照・更新可否をユーザ単位で設定可能 0 5,000,000 10,000,000 15,000,000 20,000,000 25,000,000 30,000,000 35,000,000 40,000,000 0 1,000 2,000 3,000 4,000 5,000 6,000 権限設定レコード数ユーザ数権限設定レコードの洗い替え処理を 1トランザクションで処理すると、指数関数的にトランザクションが巨大化

Slide 17

Slide 17 text

Scalable Design トータルで処理するレコード数は変わらないが、並列処理によりスループットが向上 Transaction A Transaction B Transaction C Transaction D 並列処理

Slide 18

Slide 18 text

実装例 Web Server Consumers Amazon SQS Queue A Database User Consumer Amazon SQS Queue B メッセージ分割並列処理

Slide 19

Slide 19 text

Slide 20

Slide 20 text

終わらないバッチ処理 0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 4,000,000 4,500,000 DIGITIZATIONS / MONTH DIGITIZATION VOLUME TREND

Slide 21

Slide 21 text

Non-scalable Design var targetBizCards = GetBizCardsByDigitizedTimestamp(from, to); foreach (var targetBizCard in targetBizCards) { DoSomething(targetBizCard); } 0 500,000 1,000,000 1,500,000 2,000,000 2,500,000 3,000,000 3,500,000 4,000,000 4,500,000 2016-05 2016-06 2016-07 2016-08 2016-09 2016-10 2016-11 2016-12 2017-01 2017-02 2017-03 2017-04 DIGITIZATIONS / MONTH DIGITIZATION VOLUME TREND 処理時間がデータ化の量に比例

Slide 22

Slide 22 text

Scalable Design 1件のデータ化後続処理B 後続処理A 1日中、並列処理されている 1件ずつすぐに後続処理を起動 (Domain Event) • バッチウィンドウが1日中に • 後続処理が並列化

Slide 23

Slide 23 text

Domain Eventとは NOT Domain Event Domain Event Operation A Operation C Operation A A Completed Event Operation B Operation C B Request C Request Aは後続処理を知らない Operation B Aは次にBなことを知っている Event Aggregator 事前にEvent AggregatorにSubscribe

Slide 24

Slide 24 text

Domain Eventの実装例 Publisher Amazon SNS Topic Amazon SQS Subscriber Queue A Subscriber A Subscriber B push pull Amazon SQS Subscriber Queue B

Slide 25

Slide 25 text

Slide 26

Slide 26 text

急激に変化するデータベース負荷 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 90,000 100,000 110,000 120,000 WRITES / HOUR DIGITIZATION THROUGHPUT

Slide 27

Slide 27 text

データベース負荷を安定させる 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 80,000 90,000 100,000 110,000 120,000 WRITES / HOUR DIGITIZATION THROUGHPUT 平均値「後回し」にできれば負荷が安定

Slide 28

Slide 28 text

データ化処理のアーキテクチャ Web API Server Consumer Amazon SQS Queue Database Digitization Service Consumerの並列度の制御により負荷を均すメッセージキューにより「後回し」を実現

Slide 29

Slide 29 text

並列度の制御 Consumer Database • インスタンス並列度 • Auto Scaling等を利用すれば手軽 • スレッド並列度 • .NETであればSemaphoreSlim クラス等を利用して自前実装 Consumerの並列度の制御により負荷を均す

Slide 30

Slide 30 text

while (true) { IDisposable throttlingToken = null; try { throttlingToken = await ThrottlingPolicy.EnterAsync(); var message = await MessageChannel.ReceiveAsync(); if (message == null) { throttlingToken.Dispose(); var interval = IdleRetryPolicy.GetRetryInterval(++idleCount); await Task.Delay(interval, cancellationToken); continue; } idleCount = 0; Task.Run(async () => SemaphoreSlimクラス等を利用してスレッド並列度を制御 Channelからメッセージを取得ワーカースレッドを起動 ※イメージです

Slide 31

Slide 31 text

Slide 32

Slide 32 text

メンテナンス前 (従来) データ化サービス (Digitization Service) Developers Developers 停止依頼停止

Slide 33

Slide 33 text

メンテナンス前 (現在) データ化サービス (Digitization Service) Developers

Slide 34

Slide 34 text

メンテナンス中 Web API Server Amazon SQS Queue Digitization Service データ化サービスから見ると平常運転メッセージが処理されず溜まっていく

Slide 35

Slide 35 text

メンテナンス完了時 Web API Server Consumer Amazon SQS Queue Database Digitization Service メンテナンス中に溜まったメッセージを処理

Slide 36

Slide 36 text

Slide 37

Slide 37 text

リカバリ不可能な処理メッセージングなし • リトライは自前実装 • 落ちた箇所によってはリカバリ不可能メッセージングあり • リトライは標準装備 • リトライしても失敗し続けた処理はDead Letter Queueへ • 処理内容がテキストで表現されているので、必ずリカバリ可能タイムアウト、外部サービス障害等による処理失敗時

Slide 38

Slide 38 text

メッセージングの注意点銀の弾丸はない

Slide 39

Slide 39 text

注意点 • 冪等性を保証する必要がある • 順序は保証されない (Amazon SQS Standard Queue) • 結果整合性モデルになることが多い

Slide 40

Slide 40 text

注意点 • 冪等性を保証する必要がある • 順序は保証されない (Amazon SQS Standard Queue) • 結果整合性モデルになることが多い

Slide 41

Slide 41 text

冪等性 (べきとうせい) とはある操作を何回行っても結果が同じこと REST API設計の議論で HTTP POST (冪等でない) とHTTP PUT (冪等) の意味の違いインフラ界隈で ChefやAnsibleで実現されている

Slide 42

Slide 42 text

メッセージングと冪等性 • Amazon SQSは基本、At-Least-Once Delivery (Standard Queue) Exactly-Once ProcessingモデルのFIFO Queueもあるが、遅い & Tokyoに来ていない • 例外発生等によりメッセージの処理に失敗した場合、該当処理はリトライされる冪等性を保証する必要がある強い一貫性モデル (ACID) を持つRDB等で保証するのが基本

Slide 43

Slide 43 text

注意点 • 冪等性を保証する必要がある • 順序は保証されない (Amazon SQS Standard Queue) • 結果整合性モデルになることが多い

Slide 44

Slide 44 text

順序は保証されない • Amazon SQSは基本、順序保証なし (Standard Queue) FIFOを保証するFIFO Queueもあるが、遅い & Tokyoに来ていない順序保証は自前で行う必要があるメッセージの処理の最後に次のメッセージを送信する等

Slide 45

Slide 45 text

注意点 • 冪等性を保証する必要がある • 順序は保証されない (Amazon SQS Standard Queue) • 結果整合性モデルになることが多い

Slide 46

Slide 46 text

結果整合性モデルになる例 Transaction A Transaction B Transaction C Transaction D 並列処理 Transaction AとBしか終わっていない時点では、ビジネストランザクションとして整合性が取れていない許容できない場合、分割後の全てのメッセージ処理が完了するまで処理結果を見せない等の制御が必要

Slide 47

Slide 47 text

まとめ伝えたいことを改めて

Slide 48

Slide 48 text

まとめ • メッセージングを使うことで以下を向上できる • スケーラビリティ • 堅牢性 • 運用性 • 反面、設計難易度・複雑度は上がる傾向にある特性を知り、適切な場面・方法で使用すべし