アジェンダ

Stock同期APIの仕様について、主に負荷対策面での問題点を記載する。

ゴール

• 問題点に関する認識合わせ
• 対処方針の決定

問題点

現在のStock同期処理は以下の問題があると思われる。

1. 同期処理なので、Stock数が多いユーザーが連続で利用するとAPIサーバーの負荷が上昇しサービス全体が利用出来なくなる可能性がある
2. Stock数が多いユーザーが複数人使用すると、DBのデータ量が爆発的に増える可能性がある

2 のDBのデータ量に関してはAuroraを利用しているので、それほど問題ではないが、料金が増える可能性がある。

1 の問題に関してはリリース直後、それほどユーザー数が多くない時でも問題になる可能性があるので何とか解決したい。

案1 Stock同期処理をworker用のコンテナに移譲する

下記の図の通り。

今使っているLaravelだと この機能 を利用すれば実現出来る。

メリット

• 今のStock同期のコードをそのまま流用出来る
• Laravelの機能だけで完結出来る

デメリット

• 初期リリースからDockerでの運用が必須になる
• 2 の問題を解決出来ない

ちなみに物理的にはEC2インスタンスでも対応は可能。

しかしその場合、単純にEC2インスタンスを数台立てる事になるので料金に優しくないという弱点がある。

案2 Stock同期処理をworker用のLambda関数に移譲する

下記の通り。

メリット

• 案1と比較してサーバーはEC2インスタンス1台で済むので料金に優しい

デメリット

• Lambda関数でStock同期処理を新たに書く必要がある（今までのコードが再利用出来ない）
• 2 の問題を解決出来ない

案3 Stock同期の仕様を変更する

• ラベルなしのStockを選択した際はStock取得APIを呼び出してそのユーザーのStockをページング形式で取得する
• qiita-stockerのオリジナルCategoryを付けた記事のみをqiita-stockerのDBに保存する

メリット

• 2 の問題も含めて全ての問題を解決出来る

デメリット

• 仕様変更になるので、単純に工数がかかる
• この仕様にした場合、UIの設計をどうするかが難しい

結論

案3で行く！