月次会発表切り抜き Vol.6 〜@cosme BEAUTY DAY負荷対策でEFS→S3移行した話

はじめまして、T&C開発センター第3開発本部の山田です。

T&C開発センターでは毎月月次会をおこなっており、センター全体に向けて各部から取り組みや成果の共有、各種委員会からのお知らせなどをしています。

今回はその中から、@cosme SHOPPING で @cosme BEAUTY DAY 負荷対策として実施したEFS→S3への静的ファイル移行について、当時のスライドを元にご紹介します。
（@cosme BEAUTY DAY とは？毎年12月に @cosme が開催する化粧品・コスメ通販スペシャルイベントです）

今回の課題

@cosme SHOPPING では Amazon EC2 Auto Scaling を利用して、アクセス数が急上昇しても上手く負荷分散できる仕組みにしています。
（AWSへの移行話は過去の記事で語られていますので、是非ご覧ください）

また、以前の構成では、サイト内の静的ページを構成するファイル（HTML、画像、cssなど）をEFSに配置していました。
ここでいう静的ページとは、エンジニアの手が入らないLPやヘルプページなどです。
EFSに置くことで、エンジニアの（手間のかかる）リリース作業がなくとも、デザイン担当チームが素早くページを編集できるようにしていました。

しかし、これが問題でした。

大型イベント（@cosme BEAUTY DAY）でアクセスが急上昇したとき、EC2は負荷に応じて増えてくれますが、EFSは1つだけ。
静的ページへのアクセスはEFSに集中し、EFSの読み書き制限を超えて表示が重くなってしまいました。

当時、EFSのグラフはこんな状態に。

（この時点ではテンプレキャッシュをEFSに置いていたり、他の要因も重なっての状況です）

対策を考える

次回の大型イベントに向けて、何か考えなくてはいけません。

いろいろな案が出てメリット/デメリットありましたが、限られた時間でできる、現在の構成を生かしたシンプルな対応として

「静的ファイルをEFSではなくS3に格納し、AWS CLIで定期的にS3→EC2へファイル同期する」

に決めました。

具体的には下記の作業を行いました。

• S3にバケット作成、EFSにある静的ファイルを全てS3にコピー

• S3→EC2への同期コマンド実行シェル作成、EC2全台のcrontabに設置

• アプリからの静的ファイル参照先をEFS→EC2へ一括切り替え

また、この方法だと同期するファイル数が多いほどCLI実行時にCPU使用率が上昇するという問題があったので

• AWS CLI実行時のリクエスト並列処理数を調整する

• 同期処理でスケールアウトしないように自動スケーリング閾値を調整する

などの対策も行いました。

S3→EC2同期コマンドはこんな感じ。
1行目は定期実行、2行目はサーバ起動時用でプロファイル指定ありです。

# 定期実行
aws s3 sync s3://shopping-bucket/src /ec2/shopping/src --exact-timestamps --delete

# サーバ起動時
aws s3 sync s3://shopping-bucket/src /ec2/shopping/src --exact-timestamps --delete --profile for_reboot

そうして今はこうなりました。

結果どうだったかというと

@cosme BEAUTY DAY 開催期間中、EFSの PercentIOLimit（読み書き制限に対する使用率）は最大26%で終了。

S3→EC2への静的ファイル同期も問題なく動作し、無事乗り切ることができました。

おわりに

最終的にやったことは非常にシンプルでしたが、サイトの静的ページ参照先を一括で切り替えるリリースは、かなりの緊張感でした。無傷でよかった。

今回は時間の都合もあり見送りましたが、個人的にはLambdaを使う方法も試してみたいです。

AWSはサービス・機能とも膨大で何をどう使うべきか迷いますが・・・知るほどにおもしろいですね。きっと。
これからも創意工夫して、@cosme SHOPPING をいいサービスにしていきたいなと思います。

アイスタイルT&C開発センターでは、みんなの創意工夫で@cosmeを改善していきたい！という仲間を募集しています。

中途採用 | istyle 株式会社アイスタイル