月次会発表切り抜き Vol.1 〜APIを10倍高速化した話

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

T&C開発センターでは毎月月次会をおこなっており、センター全体に向けて各部から取り組みや成果の共有、各種委員会からのお知らせなどをしています。今回はその中から私が9月にした発表の内容を少しアレンジしてお伝えしたいと思います。

※冒頭の名乗りとスライドタイトルで所属組織が異なりますが、今年10月に組織変更があったためです。

T&C開発センターでは去年からサイトの速度改善に注力しており、私の部では8月にWalletAPIとAffiliateAPIと呼ばれる2つのAPIの高速化をしました。社内でもあまり広くは認知されていないAPIですが、@cosmeスマホ版のサイドメニュー内の所持ポイント数や、商品ページの購入導線などで利用されています。
それぞれ別システムではありますが、改善施策は全く同じ3項目を実施しました。

1つ目の施策として、もともとPHP実装だったものをnodejs実装に書き換えました。nodejsは並列処理が得意な言語ですが、ここでは単純比較ができるよう、あえてすべての非同期処理を直列(逐次)実行するようにしています。クラス構成やメソッド構成、処理の流れも可能な限り踏襲しています。スライドのキャプチャではだいぶ見づらくて申し訳ありませんが、WalletAPI(紫)で20%ほど、AffiliateAPI(緑)で40%ほど高速化することができました。

2つ目の施策として、1つ目の施策であえて見送った非同期処理の並列化をおこないました。前述の通りnodejsは並列処理を得意としており、ちょっとした書き方の違いで直列処理を並列処理に書き換えることができます。前回改善後との比較で、WalletAPI(紫)がさらに20%ほど高速化しましたが、AffiliateAPI(緑)は変化なしでした。

アプリケーションによって並列処理化の効果の出方が全く違うのは、中で呼んでいるAPIやDBの処理時間、処理の依存関係によるものです。WalletAPIはポイント数、コイン数、クーポン数を独立して取得していてそれぞれおおよそ一様な時間がかかっている、AffiliateAPIは商品情報を取得、その商品に紐づくブランド情報を取得しているので、前者は並列化効果が大きく後者は小さい(というよりその部分は並列化できない)という結果に表れたようです。

3つ目の施策として、キャッシュヒット率の改善をおこないました。弊社では古くから存在するシステムではキャッシュ時間を比較的短くして短時間で元データの変更が反映されるようにしています。しかしこれでは元データに変更がなくても頻繁にキャッシュが揮発してしまい、キャッシュヒット率が低くなってしまいます。比較的新しいシステムではRabbitMQやkafkaを利用したPub/Subを活用し、キャッシュの有効期限を長めに設定しつつ、変更があったらメッセージを受け取って該当するキャッシュを更新するようにしており、今回もその仕組を適用しました。これによりキャッシュヒット率がほぼ100%近くになり、WalletAPIではさらに15%ほど、AffiliateAPIにおいては80%近くも高速化することができました。

おわりに

スライドのキャプチャにチラ見えしているように4分という持ち時間に詰め込んだ内容なのでテックブログとしてはかなり表面的で薄い記事になってしまったかもしれません。そう遠くないうちに改めて各施策についてもうちょっと詳細なお話ができればと思います。

また、月次会の発表としてもこれだと”ふーん、そう。”で終わってしまうんじゃない？と思われるかもしれませんが、弊社では個々が完結して業務ができるよりみんなが協力しあって進めていけることを重要視しています。そのため発表はできるだけ手間なく準備してハードルを下げみんなが気軽に発表できるようにしたり、質問や意見があれば発表の裏でチャットにわいわい書き込んでおいたり後から聞きに行ったり、次につなげていくことを大事にしています。

おわりのさいごに、施策その1のスライド中にこっそり書かれている
＞（先月のSP総合トップリメイクの話と同様の結果）
を今後の記事の布石として締めたいと思います。

アイスタイルT&Cセンターでは、みんなで協力しあって@cosmeを改善していきたい！という仲間を募集しています。