見出し画像

月次会発表切り抜き Vol.2 〜@cosme SHOPPINGのAWS移行苦労話

アイスタイル「テクノロジー＆クリエイティブ」LABO

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

T&C開発センターでは毎月月次会をおこなっており、センター全体に向けて各部から取り組みや成果の共有、各種委員会からのお知らせなどをしています。
この記事は@cosme SHOPPING(@cosmeの公式通販)のAWS移行時の話を月次会でしたときのものです。

なぜこの話を選んだのか。
アイスタイルでは現在システム基盤を完全にクラウドへ移行するプロジェクトを進めています。
古いサービスになればなるほど、サポートの終わっているFWやOSを使っていることも多いのでそのような技術負債を一蹴すべく日々頑張っています。

その先駆けとして@cosme SHOPPINGがありますが、私たちの（というか私の）苦労話が他の誰かの役に立つといいなと思いながら当時の出来事を紹介します。

事件勃発


オンプレ環境で稼働していた@cosme SHOPPING（以下ショッピング）をAWSに移行することになったきっかけの事件がありました。
忘れもしない2018/07/02。

とある有名歌手がコスメブランドとコラボし、アイシャドウが数量限定で販売されました。7/1にドラッグストアなどで発売開始されましたが即完売店舗が続出、7/2 10時から販売開始だったショッピングには販売開始前からアクセスが集中しサイトは重く・・・その後とうとう応答がなくなり画面が真っ白に。

同日13時にメンテナンス画面に切り替えましたが、DBに詰まったリクエストがさばけずに夜までサイトを再開することができませんでした。
この日の最大アクセスは400req/sec。
※のちに400req/secはショッピングのあらゆる案件で負荷テストの基準になる。

そんな事件の後すぐに「今年の12月に@cosme BEAUTY DAY（※）を開催する」と周知され、オンプレじゃ無理！AWS移行する！という流れに。
私はチームに異動してきたばかりで、仕様もサーバ構成もわからないままにショッピング移行担当として対応することになります。

※@cosme BEAUTY DAYとは
https://www.cosme.com/static/campaign/dir/rule/

初めてのクラウド移行対応はわからないことだらけでしたが、
その中でも私を困らせたベスト3（ワースト3？）を紹介します。

図1

その1


アプリケーションのデプロイにはCodeDeployを採用しました。デプロイ対象のEC2インスタンスにCodeDeployのAgentをインストールする必要があるんですが、できない・・・。
エラーを見るとどうやらRuby2.0以上が必要だけど我らCentOS6だから1.8までしか自動で設定されずに怒られているようでした。
rbenvを使用し2系を入れてみてもうまく自動認識されなかったので、いろいろ試した結果、シンボリックリンクを貼って対応しました。

lrwxrwxrwx 1 root root 23 10月 10 20:30 2018 ruby -> /root/.rbenv/shims/ruby

その２


キャッシュ機能にはElactiCache（memcached）を採用しました。
PHPからElactiCacheを使うためにはElastiCache Cluster Client for PHPという専用のパッケージが必要です。
インストールまでは手順通りに進み、あとはnewして使うだけと思ったらmemcachedがサーバにインストールされていない！（memcaheは存在する）＞＜
memcachedをインストールするためにyum installしたのですが、元々のPHPバージョンが低かったために同時に上がってしまいアプリケーションがあらゆるところでエラーを吐く事態に・・・dry runしていたのに。
結局設定できずに、環境ごとにmemcacheを使うかmemcachedを使うかを定数定義して回避しました。

// MEMCACHE or MEMCACHED
define('USE_MEMCACHE_D', false);

そして一番困ったけど学んだものが最後のこちら。

その3

図2

ショッピングはテンプレートエンジンにSmartyを使用しています。
Smartyキャッシュが生成されるのでデプロイ処理中に削除を行う設定にしました。SmartyキャッシュはEFSに設置し、すべてのインスタンスから同じキャッシュファイルを参照するようにもしていました。
遂に迎えた12/3の@cosme BEAUTY DAYは、インスタンスを通常の数十倍の台数に増やし迎え撃ちました。

イベント最中にデプロイを行ったところ30分以上待っても終了しない・・・しかもなんか動作がとても重い・・・
この時は急を要する修正だったため、手分けして72台を直修正したのですがその後振り返りを行った結果、以下のことが起こっていた（であろう）と判明。

図3

CodeDeployのエラー情報には
「afterinstall.shが900秒たっても完了できません」というような英語のメッセージが表示されていました。そしてこの時EFSのIOエラーも出ていました。
afterinstall.shはCodeDeployのLifecycleEvent：AfterInstallというタイミングでhookしているスクリプトなんですがSmartyキャッシュの削除などをこの中で行っています。
template_c（Smartyキャッシュのディレクトリ）を置いていたEFSはすべてのインスタンスから参照できるようにマウントしてたので、すべてのインスタンスのテンプレートキャッシュは同じパスに吐き出されます。
つまり

デプロイの完了したインスタンスにアクセスがある
↓
template_cにキャッシュファイルが作成される
↓
Afterinstallシェルで削除する
↓
template_cにキャッシュファイルが作成される

の繰り返しが発生し、CodeDeployがこける・・・
キャッシュファイルの作成と削除が延々と繰り返されEFSが限界に達し、デプロイ処理もおかしいことに、というカオスになっていました。

ログ管理の設計には気を付けよう、と教訓になりましたし冷静に考えたら同じキャッシュファイル参照するなんて怖いことしてたな、と学びを得た出来事でした。

色々事件を起こしながら初回の@cosme BEAUTY DAYを無事に終了することができました。
参考になったかどうかわかりませんが、、、お読みいただきありがとうございます。

今後、ますますアイスタイルのクラウド移行は盛り上がっていくと思います。
一緒に盛り上げたい方を募集していますので興味のある方はぜひご連絡を！

おわり


この記事が気に入ったらサポートをしてみませんか？