Bonfire Backend「業務におけるwebサービスのパフォーマンス改善」

こんにちは！Bonfire Backend運営の松本です。
12月5日に弊社のコワーキングスペースLODGEにてBonfire Backendを開催しました！

Bonfire Backendとは、サーバーサイド技術にフォーカスした情報共有を定期的に行う勉強会/交流会イベントです。
前回はBonfire "API"という名前でしたが、より広いテーマを扱えるようBonfire "Backend"と名前を変えての開催です！
目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見や発見を得たり技術交流の輪を広げたりすることのできる場を目指しています。

テーマ「業務におけるwebサービスのパフォーマンス改善」

Bonfire Backend第2回のテーマは「業務におけるwebサービスのパフォーマンス改善」です。
Bonfire恒例の乾杯の挨拶「3! 2! 1! Bonfire」から始まり、設定を工夫するチューニングから、「なんでパフォーマンス改善するんだっけ？」まで、登壇者の方々が考える各々の『パフォーマンス改善』をお話いただきました。

ヤフーからデータ＆サイエンスソリューション統括本部の橘とヤフーショッピング フロントエンドエンジニア 兼 サービスマネージャーの笹原、ゲストスピーカーとして株式会社リクルートテクノロジーズ アプリケーションエンジニアの與那城さん（@orisano）、株式会社サイバーエージェント アドテク本部 Dynalyst プロダクトマネージャー 兼 ソフトウェアエンジニアの木村さん、VOYAGE GROUP（Zucks）の大谷さん（@katzchang）の計5名にご登壇いただきました。

1. Apache Kafkaによるログ転送とパフォーマンスチューニング

橘 拓馬
ヤフー株式会社 データ＆サイエンスソリューション統括本部 エンジニア

1人目の登壇者は2018年に新卒でヤフーに入社し、現在はヤフーの大量にあるログデータを分散システムを使って分析基盤まで伝送する仕組みを構築・運用している橘。
たくさん存在するヤフーのサービス個々のサーバーに保存されている大量のログと分析基盤を連携させるメッセージングシステム、Apache Kafkaについて話しました。

Apache Kafkaは、LinkedInで開発されたpub/sub型分散メッセージングシステムです。
pub/sub型分散メッセージングシステムとは、ログデータの送信者（Producer）と分析基盤などの受信者（Consumer）の間に、Brokerという中継者を置くことで、スケールアウトに伴いう煩雑さを撤廃し、複数のサーバー間でデータを簡単に利活用できるようにした仕組みで、Apache Kafkaは、このBrokerにあたります。
特徴としては、複数のサーバーを使用し、分散システムとして稼働させることができるなどのメリットも複数存在するが、思った通りの性能が出ない場合の確認箇所が多く、解決までに時間がかかることがデメリットとしてあげられます。

そして、橘のチームも「多くのクラスタがアイドル率90%以上の中、一部のクラスタのみアイドル率が30%を割るという問題」が発生し、その際も解決まで相当試行錯誤したそうです。

Apache Kafkaなどの、分散型メッセージングシステムは、パフォーマンスに影響する要素が多く、原因特定や切り分けの難易度が高いため違和感を嗅ぎ分けられる嗅覚も解決への近道として大事だと話していました。

2. Better Docker Image+

與那城 有さん（@orisano）
株式会社リクルートテクノロジーズ アプリケーションエンジニア

2人目の登壇者はリクルートテクノロジーズでアプリケーションエンジニアをされている與那城さん。
DockerImageを「どのように速くするか」「どのように小さくするか」についてを40分用の資料を使って半分の20分でお話いただきました。

「どのように速くするか」では、コマンドそのものを早くしようと試されていました。
RUNコマンドの中身を早くしようと検討し、GitHubから実行ファイルをcurlまたはwgetでダウンロードするのが遅いことに気づかれたそうです。
そこでどうにか早くしようと、curl -vvvコマンドを調べてみたらGitHubはS3でAccept-Ranges:bytesで並列ダウンロードが可能とのこと。
そこまで確認された與那城さんは、その問題を解決するrgetコマンドを作られたそうです。
curlに比べ約2.5倍も早くダウンロードできるようになったと話されていました。

「どのように小さくするか」では、Dockerfileは１つのRUNに全部書くと良いという都市伝説を検証するために、
連続するRUN、COPY、ADDを連結するmindコマンドを作成された與那城さん。
こちらのコマンドを用いることで実際サイズが小さくなったとのこと。
というのも、Dockerのimageは差分で管理されており、一度でもRUN、COPY、ADDを跨いでしまうとその履歴がimageに差分として残りその分大きくなってしまうとのこと。

１つのレイヤーにまとめるのが本当に正しいことかは、並列ダウンロードの恩恵やcacheの有効活用なども鑑みて、きちんと計測してから決めるべきだと話されていました。

その他にも、與那城さんはdockerに関わる様々なツールを作られており、非常にdockerに対する情熱を感じるお話でした。

與那城さんが作られたツール

• github.com/orisano/rget
• github.com/orisano/targd
• github.com/orisano/minid
• github.com/orisano/dlayer
• github.com/orisano/dignore
• github.com/orisano/castage

3. akka streamを活用したログ集計に優しいデータフローの構築について

木村 衆平さん
株式会社サイバーエージェント アドテク本部 Dynalyst プロダクトマネージャー 兼 ソフトウェアエンジニア

3人目の登壇者はサイバーエージェントへ2011年に新卒入社して以来Web広告に関わり続け、現在はDynalystのPM 兼 エンジニアをされている木村さん。
Dynalystでは、秒間200,000〜250,000リクエストを行い、1日で10TB以上のログデータを扱っており、今回はその大量のログデータを綺麗にS3まで運ぶ方法についてお話いただきました。

既に使っていたAWSが提供しているOSSのバグを見つけたのが、Akka Streamを使い始めるきっかけだったそうです。
Akka Streamの他にもKinesis FirehoseやLambda Functionの候補があったそうですが、S3にオブジェクトを配置するのには工夫が必要だったり、S3のオブジェクトの数が膨大になったりする欠点がありました。

Akka Streamには、「Source」と呼ばれるメッセージを吐き出すコンポーネント、「Flow」と呼ばれるSourceからメッセージを受け取り次に送るコンポーネント、「Sink」と呼ばれるメッセージをFlowから受け取るコンポーネントが存在する。

このFlowがアップロードした時間ではなく、ログが出力された時間ベースでS3の時間区切りのパーティションで格納されることが、タイトルにもある、「ログ集計に優しいデータフロー」の所以。
それだけではなく、集計する時間も半分に減ったとも話されていました。

4. 広告配信サービスにおけるパフォーマンス対策、やるかやらないか

大谷 和紀さん（@katzchang）
VOYAGE GROUP, Zucks

4人目の登壇者はVOYAGE GROUPの子会社であるZucksにて、Zucks Ad Networkの開発・運用を行い、CTOもされている大谷さん。
実際に体験された事例なども踏まえながら、パフォーマンス対策の必要性と、考慮すべき点についてお話いただきました。

既存のシステムからトラフィックを変更した数十分後に、広告配信のパフォーマンスが悪化した事例をお話くださいました。
問題が発生した時は、スケールアウト・アップして対策したことで、最初の想定より、20倍ほどサーバー費がかかったそうです。

その後、直前に行なった「広告キャンペーンの有効化」のコードを確認し、使用していたライブラリのJSONをパースする処理で時間がかかっていたことが原因だと気づかれたようです。

パフォーマンス対策を実施する上で、「計測」「仮説」「実験」の３つが大事だとお話されていた大谷さん。
その中でも特に、開発者が実験しやすい環境を整え、ツールや手法などのアイデアを試すことができる権限を持つことが大事とのことでした。

5. SpeedCurveを駆使した継続的なパフォーマンス改善

笹原 翼
ヤフー株式会社 ショッピング統括本部 エンジニア

5人目の登壇者はヤフーショッピングにて、技術部長 兼 SMで最近はフロントエンドエンジニアをしている笹原。
技術部長 兼 SM（サービスマネージャー）という立場だからこそ見える、技術 / サービスの両目線から見たパフォーマンスについて話しました。

パフォーマンス改善に関しての技術目線では「とにかく速くしたい」や「パフォーマンス改善に時間をくれ！」などを上げられるのに対し、サービス目線での意見としては「〇〇に時間がかかって苦情がくるので改善してほしい」や「効果がわからない速度改善より他をやってほしい」などがあり両者の意見が食い違う中、両者が納得持って進められるやりかたを探したと話していました。

そこで取ったやり方が「サービスのKPIとパフォーマンスの因果関係を証明する」というものだったそうです。
ヤフーショッピングは、この速度（パフォーマンス）とKPIの相関を証明できた結果、速度改善PJの立ち上げに成功し、速度改善により多くのリソースを割けるようになりました。

フロントエンドエンジニアでもある笹原は、時々「そのAPI、速くしても意味ないのに」と思うことがあると話していました。
例えば、「直列処理で叩いているAPIよりも、非同期で叩いているAPIを改善する場合」や、「非同期で叩いているAPIの中で明らかにボトルネックになっているものがあるのに、それ以外のAPIを改善しようとしている場合」などが上げられるそうです。

ですので、パフォーマンスを改善する際には、サービス全体の現状を把握し、改善すべき優先度をつけることが大切とのことでした。

まとめ

Bonfire Backendでは「業務におけるwebサービスのパフォーマンス改善」をテーマとして異なる会社・サービスを提供する５名の方々にそれぞれの視点でお話を頂きましたが、みなさん「計測することの重要性」という点に関しては共通していたのではないかと思われます。

パフォーマンス改善を行いたくても、「本当にその改善は必要何だっけ？」と考え、一度踏みとどまる事の重要性
どうしても行いたい場合には、「サービスのKPIとパフォーマンスの因果関係」を証明すると実現できる可能性が高くなることなど実際のチューニング技術だけではなく、技術以外のパフォーマンス改善に関わる知見も得ることができたのではないかと思います。

今後もBonfire Backendは目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見や発見を得たり技術交流の輪を広げたりすることのできる場として開催していく予定です。

photo credit : 福島 シオン

Yahoo! JAPAN主催の技術・デザインコミュニティー「Bonfire」では、定期的に勉強会を開催しています。
connpassで告知していますので、ぜひご参加ください。
https://yj-meetup.connpass.com/