パフォーマンス向上とリソース管理のためのアプローチ / RAKUSTechCon2024_RLC

◆イベント名
RAKUS Tech Conference 2024
https://techcon.rakus.co.jp/2024/

◆発表タイトル
パフォーマンス向上とリソース管理のためのアプローチ

◆登壇者
株式会社ラクスライトクラウド 企画課　牧野寛知
株式会社ラクスライトクラウド BMバックエンド開発課　上原崇

Transcript

1. パフォーマンス向上と 
 リソース管理のための 
 アプローチ 
 ラクスライトクラウド企画課　牧野寛知
 ラクスライトクラウド開発部　上原崇

2. 登壇者紹介 ラクスライトクラウド企画課 牧野寛知 2022年ラクス入社。 青山学院大学国際政治経済学部卒業後、株式会社ジーニー に入社。アドテク、 SaaS領域で事業開発を担当した後、株式会 社ラクス/株式会社ラクスライトクラウドのブラストエンジンチー ムにプロダクト・マーケティング・マネージャーとして参画し、 メール市場における自社の製品戦略の策定などに従事。 ラクスライトクラウド開発部 上原崇 2006年ラクス入社。 未経験から人材派遣事業（※現・株式会社ラクスパートナー ズ）の研修を経て顧客案件の開発保守を経験後、 2008年から 自社サービス開発に異動。レンタルサーバ事業の開発保守 や、楽楽明細の開発立ち上げを経験し、 2018年からブラスト メールと2021年に新たに立ち上げたブラストエンジンのリード エンジニアを務める。 2

3. 本日のトピック 3
 1. ラクスでエンジニア向けプロダクトを作っている理由 2. blastengine安定性と利便性向上のための課題とアプローチ ◦ パフォーマンスの課題 ◦ ユーザリソース管理の課題
4. 4
 ブラストエンジンはAPI連携やSMTPリレーでのメール配信が可能な、システム連携に特化したメール配信エンジンです。 お客様システム 宛先ごとにカスタマイズ された独自配信エンジン docomo用 softbank用 au用 Gmail用 Apple用 RESTful API SMTPリレーサーバー API連携（配信系） SMTPリレー API連携（取得系） 私たちの部門で担当している製品
5. ブラストエンジンとは（ブラストメールとの違い） ざっくり言うと ・ブラストメール： HTMLエディタが欲しい・宛先管理したい ・ブラストエンジン： 宛先管理は自前でやる・配信機能だけ使いたい 5

6. ブラストメールから機能を省いてサービス提供 　ブラストメールの特徴 　　・ブラウザ上のエディタでメール文面を書く 　　・宛先管理ができ、配信停止の受け付けや管理ができる 「エディタも宛先管理も要らない、別で持っているから」というユーザが一定数いた。 そこで、画面でのメール作成や宛先管理を省いてリリースしたのがブラストエンジン。 APIやSMTPでメール配信を受け付けて配信する。 6
 ラクスでエンジニア向けプロダクトを作っている理由
7. エディタまで作るならメールサーバーも作ればいいのに。。。 7
 ラクスでエンジニア向けプロダクトを作っている理由
8. エディタまで作るならメールサーバーも作ればいいのに。。。 8
 メールサーバーが難しいんです。 サービスのスケールにしたがって運用負荷が高くなる。 ラクスでエンジニア向けプロダクトを作っている理由
9. 9
 ・メール送信に使う IP、ドメイン単位でレピュテー ション（評判）という概念がある。 ・受け手側のサーバーが非公開の基準で個別に 持っており、レピュテーションが低いとスパム扱い されてメールが届かなくなる。 ・宛先が存在しない、スパム判定された、受け先の エラーなど結構エラーが出る。 ・メールの世界には統一されたエラー規格がない ので、GmailとAppleで同じ要因でも違うエラー文 言が出るし、日々新しい種類のエラーが定義され 続ける。 ・スパムメールの送信者と疑われる IPやドメインを 一覧化したブラックリストを提供する団体が無数に あり、Gmailなどでもスパム判定の基準に使われ ている。 ・機械的な基準で掲載されるため、スパムを送って いなくても、一時的に掲載されメールが届かなくこ とがある。 ラクスでエンジニア向けプロダクトを作っている理由 エラーハンドリング レピュテーション管理 ブラックリスト対応 メールサーバーの３大運用負荷
10. ラクスでエンジニア向けプロダクトを作っている理由 10
 エラーハンドリング ・メール送信に使う IP、ドメイン単位でレピュテー ション（評判）という概念がある。 ・受け手側のサーバーが非公開の基準で個別に 持っており、レピュテーションが低いとスパム扱い されてメールが届かなくなる。 レピュテーション管理 ・宛先が存在しない、スパム判定された、受け先の エラーなど結構エラーが出る。 ・メールの世界には統一されたエラー規格がない ので、GmailとAppleで同じ要因でも違うエラー文 言が出るし、日々新しい種類のエラーが定義され 続ける。 ブラックリスト対応 ・スパムメールの送信者と疑われる IPやドメインを 一覧化したブラックリストを提供する団体が無数に あり、Gmailなどでもスパム判定の基準に使われ ている。 ・機械的な基準で掲載されるため、スパムを送って いなくても、一時的に掲載されメールが届かなくこ とがある。 メールサーバーの３大運用負荷 メール技術なんて詳しくないし、正直こんな運用やってられない という企業が多かった。
11. 11
 顧客がメール運用から解放され コアな業務に向き合うことができる環境を作るために、 メール運用を自動化するクラウドツールが必要だった。 メール技術なんて詳しくないし、正直こんな運用やってられない という企業が多かった。 ラクスでエンジニア向けプロダクトを作っている理由
12. 本日のトピック 12
 1. ラクスでエンジニア向けプロダクトを作っている理由 2. blastengine安定性と利便性向上のための課題とアプローチ ◦ パフォーマンスの課題 ◦ ユーザリソース管理の課題
13. 安定性や利便性に関わる懸念点 ・APIでの処理に時間が掛かってタイムアウトが発生する ・ユーザによるAPIリソースの集中的な利用が発生する ・宛先の一括登録に時間が掛かる 13 弊社の別サービスの運用で得ていた知見があった
14. 安定性や利便性に関わる懸念点 ・APIでの処理に時間が掛かってタイムアウトが発生する ・ユーザによるAPIリソースの集中的な利用が発生する ・宛先の一括登録に時間が掛かる 14
15. APIでの処理に時間が掛かってタイムアウトが発生する 同期的なAPIで設計すると ・リクエストを受け付けて、そのまま APIサーバで処理を実施 ・処理が完了してからレスポンスを返す 15 ・軽い処理では問題なし ・時間の掛かる処理では、レスポンスを返すまでにタイムアウトが発生することがある 処理が打ち切られたのかな？　 API側では処理が続いてるのかな？ ユーザ
16. APIでの処理に時間が掛かってタイムアウトが発生する 非同期的な API設計を採用 ・時間の掛かる処理をバックグラウンド処理で実行 ・APIは処理の完了を待たず即座にレスポンスを返す ・実処理の情報はタスクキューに入れる ・バックグラウンドで順次実行 16
17. APIでの処理に時間が掛かってタイムアウトが発生する 結果 ・タイムアウトのリスクを低減 ・APIサーバが高負荷になるリスクを低減 ・役割を分けることでスケールのコントロールがし易い 17
18. 安定性や利便性に関わる懸念点 ・APIでの処理に時間が掛かってタイムアウトが発生する ・ユーザによるAPIリソースの集中的な利用が発生する ・宛先の一括登録に時間が掛かる 18
19. ユーザによる APIリソースの集中的な利用が発生する APIに利用制限を設けていないと ・リクエスト数などによる課金が無い ・リクエスト数などによる利用上限も無い ・ユーザ操作で想定外に大きくリソースを消費するリスクがある ・各ユーザに公平にリソースを使ってもらうことができなくなる 19
20. ユーザによる APIリソースの集中的な利用が発生する 事例：5万件の宛先を登録する ・方法１：CSVによる5万件の一括登録 ←実行時の効率はこちらが良い ・方法２：1件ずつの宛先登録を5万回ループ ←実装は楽 ・方法２の1件ずつ5万回は通信などのオーバーヘッドが大きく時間が掛かる 　　→長時間にわたり大きくリソースを利用される 20 いつもより遅いな 他の ユーザ
21. ユーザによる APIリソースの集中的な利用が発生する レートリミット (RateLimit)の採用 ・ユーザのAPIリクエスト数に時間あたりの上限を設ける 　　→1リクエストすると残り回数が1減る 　　→残り回数は時間経過で回復 21
22. ユーザによる APIリソースの集中的な利用が発生する レートリミット (RateLimit)の採用 ・超過したらステータスコード429を返す 　　→リクエスト可能になるまでの時間はレスポンスヘッダに載せる 　　→ユーザは429を受けたら何秒待てばいいか分かる ご紹介まで（APIはJava実装） ・RateLimitライブラリ：Bucket4j ・bucketの共有：Hazelcast 22
23. ユーザによる APIリソースの集中的な利用が発生する 結果 ・リクエスト数が制限されているので APIサーバが安定 ・ユーザにとって偏ることなく公平なリソース配分 ・制限を明示されることで、ユーザも過剰消費しない設計にしてくれる 23
24. 安定性や利便性に関わる懸念点 ・APIでの処理に時間が掛かってタイムアウトが発生する ・ユーザによるAPIリソースの集中的な利用が発生する ・宛先の一括登録に時間が掛かる 24
25. 宛先の一括登録に時間が掛かる ブラストエンジンでは宛先を毎回登録する ・ブラストエンジンには宛先管理機能がない 　　→宛先は配信予約の際に都度登録する ・宛先をCSV一括登録するのに時間が掛かると、配信準備の時間が長くなる ・準備時間を見越して予約を始めていただければ良いが、長すぎると不便を感じるポイントに 25
26. 宛先の一括登録に時間が掛かる MongoDBの採用 ・高い書き込み性能 ・宛先などを登録する処理が早く終わる 26
27. 宛先の一括登録に時間が掛かる 結果 ・実績紹介）100万件を5分でインポート完了 　　→負荷状況やメールに差し込む個別情報の量にもよる 　　→ここでは　宛先メールアドレス＋名前などの差し込みを 3項目　で検証 27
28. 宛先の一括登録に時間が掛かる MongoDBのつまずいたポイント ・大量のドキュメントを持つコレクションではページング (skip)検索のレスポンスが遅い 　　→skip件数が多いほど性能が劣化 　　　　・後ろのページ番号になるほど時間が掛かる 　　→使い方としては、skip件数を少なく保てるUIがオススメ 　　　　・ページ番号ではなく「次へ」「前へ」のみの UI 　　　　・インデックスの効いた日時などで必ず絞る UI 28
29. まとめ ブラストエンジンのアプローチ ・時間のかかる処理はバックグラウンドに ・レートリミット(RateLimit)でリソース配分を公平に ・MongoDBの採用で宛先データのインポートを高速に ・ユーザに安定したシステムを提供し、利便性を向上させる 29
30. ご清聴ありがとうございました。 30