Sansan がメッセージング (Amazon SQS) でスケーラビリティを手に入れた話: using C# on Windows

Size: px

Start display at page:

Download "Sansan がメッセージング (Amazon SQS) でスケーラビリティを手に入れた話: using C# on Windows"

わんどあさま
5 years ago
Views:

1 Sansan がメッセージング (SQS) でスケーラビリティを手に入れた話 using C# on Windows; AWS Dev Day Tokyo 2017

2 自己紹介 Development Manager at Interested in Domain-Driven Design C# /.NET Enterprise Integration Patterns

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

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

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

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

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

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

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

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

12 ミドルウェア 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 で採用

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

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

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

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

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

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

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

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

21 DIGITIZATIONS / MONTH Non-scalable Design var targetbizcards = GetBizCardsByDigitizedTimestamp(from, to); foreach (var targetbizcard in targetbizcards) { DoSomething(targetBizCard); } 処理時間がデータ化の量に比例 4,500,000 4,000,000 3,500,000 3,000,000 2,500,000 2,000,000 1,500,000 1,000, ,000 0 DIGITIZATION VOLUME TREND

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Python Perl JavaScript および PHP などのランザクション ID を利用することで重複する処理な Tuple が流れるかはグルーピングより決定されま多くの言語をサポートしていますを判別することができますす 6 簡単なデプロイと運用は簡単にデプロイし動作させるこ

Python Perl JavaScript および PHP などのランザクション ID を利用することで重複する処理な Tuple が流れるかはグルーピングより決定されま多くの言語をサポートしていますを判別することができますす 6 簡単なデプロイと運用は簡単にデプロイし動作させるこ春の嵐吹く Twitter 社が公開したオープンソースリアルタイム分散処理日々発生する大量なデータをリアルタイムに処理し続けるストリームデータ処理に対するニーズが高まっています同じビッグデータでもバッチ処理の Hadoop とはまた違った解決方法が求められる分野です本記事ではそのストリームデータ処理を実現するプロダクトとして今注目を集めているについて解説しますビッグデータリアルタイム