[Developers Summit 2015 講演資料] リクルートテクノロジーズ 14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と

1. 株式会社リクルートテクノロジーズ ITマネジメント統括部 ITマネジメント1部スマートデバイスグループ樋口勝彦 14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と解～ 2015/2/20

2. 2 ひぐちかつひこ樋口勝彦株式会社リクルートテクノロジーズ ITマネジメント統括部 ITマネジメント1部スマートデバイスグループ自己紹介 3年間SIer 2年間決済系システム開発リクルート 2013/5～ Tizen アプリ開発 Pusna開発（プッシュ通知基盤） FirefoxOS アプリ開発幻の (C) Recruit Technologies Co.,Ltd. All rights reserved.

9. 9(C) Recruit Technologies Co.,Ltd. All rights reserved. メルマガに比べて開封率が高く、リアルタイム性があり効果的な販促ツールとして認知されているプッシュ通知の特徴ユーザのアクティブ率向上に効果的： • リアルタイム性を考慮した情報推薦 • 休眠ユーザの再起アプリでの利用例: 新鮮度がある/話題になるニュースをお届け！登録条件に合致する新着物件をお知らせ！自分に好意を持った人をお知らせ！

12. 12 プッシュ通知対応の工数削減を目的にプッシュ通知基盤をフィジビリ・サービスとして各アプリに展開 Pusna Push Notification Aggregator プッシュ通知基盤

13. 13 当時のシステム構成開発言語 Ruby 1.8系 FW Rails 2.3系 DB MySQL 5.4系 APNs デバイス登録プッシュ依頼 Pusna GCM

14. 14 デバイス登録数の遷移 11年6月プッシュ通知基盤 Pusna フィジビリ・サービス化時間登録デバイス数 2011.06

15. 15 デバイス登録数の遷移 11年6月時間登録デバイス数プッシュ通知基盤 Pusna フィジビリ・サービス化 2011.06

16. 16 デバイス登録数の遷移 X,000,000 11年6月 13年5月 13年7月12年8月時間

17. 17 デバイス登録数の遷移 X,000,000 11年6月 13年5月 13年7月12年8月 X00万デバイス越時間 2012.08

18. 18 デバイス登録数の遷移 X5,000,000 11年6月 13年5月時間

19. 19 デバイス登録数の遷移 X5,000,000 11年6月 13年5月時間樋口リクルートテクノロジーズ入社 2013.05

20. 20 デバイス登録数の遷移 X5,000,000 11年6月 13年5月 2013.05 樋口入社この頃樋口は、

21. 21 デバイス登録数の遷移 X5,000,000 11年6月 13年5月 2013.05 樋口入社 (幻の) アプリ開発に。

22. 22 デバイス登録数の遷移 X5,000,000 11年6月 13年5月 2013.05 樋口入社 (幻の) アプリ開発に。

24. 24 デバイス登録数の遷移 X0,000,000 11年6月 13年7月

25. 25 デバイス登録数の遷移 X0,000,000 11年6月 13年7月樋口 Pusna のチームリーダーに。 2013.07

26. 26 デバイス登録数の遷移 X0,000,000 11年6月 13年7月樋口 Pusna のチームリーダーに。 2013.07 当時システムは既に限界を迎えていた

27. 27 デバイス登録数の遷移 X0,000,000 11年6月 13年7月樋口 Pusna のチームリーダーに。 2013.07 (システム構成図) デバイス登録 APNs Pusna GCM プッシュ依頼

28. 28 デバイス登録数の遷移 X0,000,000 11年6月 12年8月 13年5月 13年7月 2013.07 樋口チームリーダー抜擢デバイス数急増 APNs Pusna GCM プッシュ依頼デバイス登録

31. 31(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「配信スピードが遅く、届けたいタイミングでメッセージが送れない。」 └1000万件の配信に1週間を要した。問題2: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」 └各アプリ担当者のプッシュ時間を調整する必要あった。

33. 33(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「配信スピードが遅く、届けたいタイミングでメッセージが送れない。」 └1000万件の配信に1週間を要した。問題2: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」 └各アプリ担当者のプッシュ時間を調整する必要あった。配信処理開始配信処理終了問題1 特定時間帯を狙った訴求ができない (例: 昼休み) 昼休み終了効果的効果が期待できない

35. 35(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「配信スピードが遅く、届けたいタイミングでメッセージが送れない。」 └1000万件の配信に1週間を要した。問題2: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」 └各アプリ担当者のプッシュ時間を調整する必要あった。当時、樋口の仕事問題2 好きな時間にプッシュ依頼ができない。

36. 36(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事システム担当者今日のプッシュスケジュール教えてください

37. 37(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事 Aアプリ担当 12時からプッシュする予定です。システム担当者今日のプッシュスケジュール教えてください

38. 38(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事 Aアプリ担当 12時からプッシュする予定です。システム担当者今日のプッシュスケジュール教えてください Bアプリ担当 12時からプッシュする予定です。

39. 39(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事 Aアプリ担当 12時からプッシュする予定です。システム担当者今日のプッシュスケジュール教えてください Bアプリ担当 12時からプッシュする予定です。 Cアプリ担当 12時からプッシュしたいです。

40. 40(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事Aアプリ担当 12時からプッシュする予定です。 Bアプリ担当 12時からプッシュする予定です。 Cアプリ担当 12時からプッシュしたいです。システム担当者の頭の中 3アプリ同時は無理。。 Aアプリの規模は大きいから時間かかるし、 Bはニュースアプリだから後回しできない。 Cは…(略)。 B->A->Cで調整してみよう。

41. 41(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事 Bアプリ担当 12時からプッシュする予定です。 Cアプリ担当 12時からプッシュしたいです。システム担当者 >Aさんプッシュ依頼時刻ですが、14時からに変更できないでしょうか？？ >Cさんお昼はシステムが混み合っておりまして、夕方頃プッシュが可能になる見込みです。追って、ご案内させてください。大変申し訳ございません。

42. 42(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事変更できないでしょうか？？ >Cさんお昼はシステムが混み合っておりまして、夕方頃プッシュが可能になる見込みです。追って、ご案内させてください。大変申し訳ございません。 Cアプリ担当

43. 43(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事大変申し訳ございません。 Cアプリ担当システム担当者本当に申し訳ございません。。

44. 44(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」各アプリ担当者のプッシュ時間を調整する必要あった。問題2: 「配信スピードが遅く、カスタマーに届けたいメッセージが送れない。」 1000万件の配信に1週間を要した。当時、樋口の仕事大変申し訳ございません。 Cアプリ担当システム担当者本当に申し訳ございません。。当時、樋口の仕事プッシュ配信の交通整備人俺・・・何してんだろう

45. 45(C) Recruit Technologies Co.,Ltd. All rights reserved. 当時のシステムで発生していた問題問題1: 「配信スピードが遅く、届けたいタイミングでメッセージが送れない。」 └1000万件の配信に1週間を要した。問題2: 「高負荷にシステムが耐えられないため、各アプリが好きな時間にプッシュ依頼できない。」 └各アプリ担当者のプッシュ時間を調整する必要あった。キャパシティ限界を迎えていた

50. 50 Realtime & Scalable 再構築のコンセプト

51. 51 Realtime & Scalable 数千万台デバイスのアクセスに耐える 1000万人に15分以内に配信できる再構築のコンセプト

52. 52 Pusna Push Notification Aggregator 旧プッシュ通知基盤

53. 53 Pusna Realtime Scalable

54. 54 Pusna-RS Push Notification Aggregator Realtime & Scalable 新プッシュ通知基盤

57. 機能間の非同期連携 57(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化APNs 旧Pusna GCM デバイス登録プッシュ依頼改善ポイント①

58. 機能間の非同期連携 58(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化APNs 旧Pusna GCM デバイス登録プッシュ依頼改善ポイント①

59. 機能間の非同期連携 59(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化APNs 旧Pusna GCM デバイス登録プッシュ依頼改善ポイント① 機能分割

62. 機能間の非同期連携 62(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化改善ポイント② APNs 旧Pusna GCM

63. 機能間の非同期連携 63(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化改善ポイント② APNs 旧Pusna GCM

64. 機能間の非同期連携 64(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化改善ポイント② I/Oの高速化 APNs 旧Pusna GCM

66. 66(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDBとは • Amazon DynamoDBはAWSにて提供される分散KVS。 • 複数のAZ（データセンター）にわたってレプリケーションされることで高い信頼性が保証されている。 • SSDで動作しておりデータ量の変化に関係なく高速に動作する。 • スキーマレスにデータを扱える。

69. 機能間の非同期連携 69(C) Recruit Technologies Co.,Ltd. All rights reserved. Realtime & Scalable 実現のため基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化「高速化」＆「単純化と分割」で Realtime & Scalable を実現

72. 72 Pusna-RS Push Notification Aggregator Realtime & Scalable アーキテクチャについて

74. 74(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker 登録worker 管理API データ参照事業サーバ配信担当者全体構成システム管理・操作用 Web UI SQS SQS SQSを利用した機能間の非同期連携を実現

79. 79(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API データ参照事業サーバ配信担当者デバイス登録処理 ①デバイス登録 SQS

80. 80 DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API データ参照事業サーバ配信担当者デバイス登録処理 (C) Recruit Technologies Co.,Ltd. All rights reserved. SQS スマホアプリ内の PusnaRS用SDK経由で登録APIにデバイス情報を送信 ①デバイス登録

81. 81(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API データ参照事業サーバ配信担当者デバイス登録処理 SQS デバイス情報をDynamoDBと Elasticsearchに登録 ①デバイス登録

83. 83(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API 事業サーバ配信担当者配信登録 SQS ②配信登録配信者又は事業サーバから PUSH配信をリクエスト

85. 85(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API 事業サーバ配信担当者配信依頼処理 SQS ③配信依頼配信要求を元に対象デバイスを抽出配信タイプに応じて DynamoDB または elasticsearchからデバイス情報を抽出

86. 86(C) Recruit Technologies Co.,Ltd. All rights reserved. DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker SQS 登録worker システム管理・操作用 Web UI 管理API 事業サーバ配信担当者配信依頼処理 SQS ③配信依頼抽出したデバイス情報を APNs又はGCMへ送信

88. 88 結果

89. 89 再構築 BEFORE / AFTER ✔□ Realtime 配信スピード: (旧) 秒間最大41件 (新) 秒間最大 14,000件 1000万台配信実績: (旧) 1週間 ※(分割配信) (新) 12分

90. 90 再構築 BEFORE / AFTER ✔ ✔ □ Realtime 配信スピード: (旧) 秒間最大41件 (新) 秒間最大 14,000件 1000万台配信実績: (旧) 1週間 ※(分割配信) (新) 12分 □ Scalable 登録デバイス数が数千万を超えた現在もリリースから1年以上、完全無停止で安定稼働中

91. 91 再構築 BEFORE / AFTER ✔ ✔ □ Realtime 配信スピード: (旧) 秒間最大41件 (新) 秒間最大 14,000件 1000万台配信実績: (旧) 1週間 ※(分割配信) (新) 12分 □ Scalable 登録デバイス数が数千万を超えた現在もリリースから1年以上、完全無停止で安定稼働中

92. 92 そのシステムがスマートデバイスの急速な普及により大変な状況に！そして平穏な日々を手に入れた

95. 95 そのシステムがスマートデバイスの急速な普及により大変な状況に！平穏な日々を手に入れた

96. 96 そのシステムがスマートデバイスの急速な普及により大変な状況に！平穏な日々を手に入れたはずだった・・・

99. 99 ある日の定時後アラートメールを受信

116. 116 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。対応

117. 117 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。想定対応

118. 118 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。閾値 t キューの深さ Writeスループット向上想定対応

119. 119 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。実際対応

120. 120 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。実際対応閾値 (1,000) t キューの深さ Writeスループット向上

121. 121 ある日の定時後アラートメールを受信デバイス登録キューが詰まっている (閾値1,000) [再掲] (型化されている運用通り) 該当アプリのDynamoDB スループット値(write)を上げた。実際対応キューの深さ 140万件まで膨れ上がる (ﾟ∀ﾟ；)ﾔ・・・ｬﾊﾞ. 閾値 (1,000) t キューの深さ Writeスループット向上

122. 122 該当アプリ以外の処理も遅延することにデバイス登録処理遅れています

140. 140 起きていた現象登録キュー (詰まり中) 登録APIサーバーのスケールアウト(2台->10台) 誤った打ち手2 さらに無限ループが加速

141. 141 起きていた現象登録キュー (詰まり中) 登録APIサーバーのスケールアウト(2台->10台) 誤った打ち手2 さらに無限ループが加速無限ループの影響で他アプリのデバイス登録の遅延が発生した

143. 143(C) Recruit Technologies Co.,Ltd. All rights reserved. 登録API 登録Worker デバイス登録キューELB DynamoDB elasticsearch デバイス登録アプリA アプリA アプリB アプリB アプリC 全てのアプリのデバイス登録処理を一つのキュー(SQS)で管理 BEFORE アプリAから大量のアクセスでアプリB,Cの登録処理が遅延しまった

144. 144(C) Recruit Technologies Co.,Ltd. All rights reserved. 登録API 登録Worker アプリA登録キュー ELB DynamoDB elasticsearch デバイス登録アプリA アプリA アプリB アプリB アプリC 一つのキューから大量に取得しないように取得数を制御しているアプリB登録キューアプリC登録キューアプリ毎にキュー(SQS)を分割することで遅延リスクを最小限に AFTER

145. 145 事例からの学びプラットフォームとして単体アプリの影響が全体におよぶ構成にしてはならない

148. 148 ある日の午後あるサービス担当者からの訴えプッシュ後サービス側のサーバにアクセス集中して耐えられません！何とかして！

153. 153 起きていた現象 APNs/GCM デバイス登録リクエストプッシュ後アプリ起動時に発生するデバイス登録の一斉リクエスト問題なく捌けていた Pusna-RS

154. 154 起きていた現象 APNs/GCM Pusna-RS デバイス登録リクエスト一方でサービス側のサーバは悲鳴を挙げていたしかしサービス

158. 158 起きていた現象 APNs/GCM Pusna-RS サービスに対するリクエストサービス例えば、500万デバイスにプッシュする場合 7分弱※1の間にアプリのアクティブユーザが 50万※2増えることになる ※1 配信スピード: 秒間14,000件換算 ※2 プッシュ通知の開封率: 10% 換算

159. スピード違反

160. スピード違反ではなく考慮不足

162. 162 事例からの学びサービス全体のユースケースを考慮したアーキテクチャにすべき

166. 166 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量当然、1回1回の検索時間も長くなり、負荷が高まる

167. 167 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量セグメンテーションプッシュの利用頻度も上がり、高負荷な状態は慢性化していたさらに

168. 168 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量 OutOfMemoryが発生！そんな時

169. 169 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量 OutOfMemoryが発生！一部のプッシュが遅延した。そんな時

173. 173 シャード数を増やした構成に再構築する打ち手 1シャード当たりのドキュメント数が多く検索負荷が高い問題事象「Elasticsearch高負荷」のまとめシャード 10↑ -想定Doc数変更後すぐ 500万↓Doc数/ シャード未来 10 1億 1,000万 4 5,000万現 1,250万 (C) Recruit Technologies Co.,Ltd. All rights reserved.

174. 174 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量シャード数の変更はオンラインではできない。しかし

175. 175 想定Doc数 5,000万シャード 4 レプリカ数 3 ノード数 6 Elasticsearchの構成クラスター情報想定Doc数を超え 1シャード当たり 1000万を超えるデータ量シャード数の変更はオンラインではできない。しかし

182. 182 事例からの学び継続的にシステムをモニタリングし再度未来を見立て常にアーキテクチャを最適な状態に変化させていくべき

185. 185 楽しい

186. 186 可能性

187. 187 新技術に挑戦すべき理由リスク

188. 188 新技術に挑戦すべき理由見えない

189. 189 新技術に挑戦すべき理由リスクを見立てる

190. 190 新技術に挑戦すべき理由前進

191. 191 新技術に挑戦すべき理由行き止まり

192. 192 行き止まりリリース

193. 193 新技術に挑戦すべき理由運用

194. 194 新技術に挑戦すべき理由想定外

195. 195 新技術に挑戦すべき理由リスク顕在化

196. 196 新技術に挑戦すべき理由リスクと向き合う

197. 197 新技術に挑戦すべき理由向き合う

198. 198 新技術に挑戦すべき理由向き合い続ける

199. 199 新技術に挑戦すべき理由チームが強くなる

200. 200 新技術に挑戦すべき理由貢献

203. 機能間の非同期連携 203(C) Recruit Technologies Co.,Ltd. All rights reserved. Pusna-RS アーキテクチャのポイント基本アイディア利用ツール Scalable └単純化と分散 Realtime └高速化 └各機能の高速化 └IOの高速化 DynamoDBによる I/Oの高速化非同期I/Oの活用 I/Oの最適化 DynamoDB elasticsearch クラスタデバイス登録リクエスト APNs/GCM サーバ登録API データ登録配信worker 登録worker 管理API データ参照事業サーバ配信担当者システム管理・操作用 Web UI SQS SQS SQSを利用した機能間の非同期連携を実現 I/Oの高速化

[Developers Summit 2015 講演資料] リクルートテクノロジーズ 14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と

Esté a ler uma amostra.

Confira estes a seguir

[Developers Summit 2015 講演資料] リクルートテクノロジーズ 14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Semelhante a [Developers Summit 2015 講演資料] リクルートテクノロジーズ 14,000件/秒の配信を実現したリクルートのモバイルアプリを支えるプッシュ通知基盤～AWS上での開発・運用の中で見えてきた課題と (20)

Mais de Recruit Technologies (19)

Mais recentes (8)