現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。Backend運営の松本です。Backendとは、サーバーサイド技術にフォーカスした情報共有を定期的に行う勉強会/交流会イベントです。"Backend"と名前を変えての開催です!目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見や発見を得たり技術交流の輪を広げたりすることのできる場を目指しています。Backend第2回のテーマは「業務におけるwebサービスのパフォーマンス改善」です。Bonfire」から始まり、設定を工夫するチューニングから、「なんでパフォーマンス改善するんだっけ?」まで、登壇者の方々が考える各々の『パフォーマンス改善』をお話いただきました。GROUP(Zucks)の大谷さん(@katzchang)の計5名にご登壇いただきました。エンジニア1人目の登壇者は2018年に新卒でヤフーに入社し、現在はヤフーの大量にあるログデータを分散システムを使って分析基盤まで伝送する仕組みを構築・運用している橘。Kafkaについて話しました。Kafkaは、LinkedInで開発されたpub/sub型分散メッセージングシステムです。Kafkaは、このBrokerにあたります。特徴としては、複数のサーバーを使用し、分散システムとして稼働させることができるなどのメリットも複数存在するが、思った通りの性能が出ない場合の確認箇所が多く、解決までに時間がかかることがデメリットとしてあげられます。橘のチームも「多くのクラスタがアイドル率90%以上の中、一部のクラスタのみアイドル率が30%を割るという問題」が発生し、その際も解決まで相当試行錯誤したそうです。Kafkaなどの、分散型メッセージングシステムは、パフォーマンスに影響する要素が多く、原因特定や切り分けの難易度が高いため違和感を嗅ぎ分けられる嗅覚も解決への近道として大事だと話していました。アプリケーションエンジニア2人目の登壇者はリクルートテクノロジーズでアプリケーションエンジニアをされている與那城さん。DockerImageを「どのように速くするか」「どのように小さくするか」についてを40分用の資料を使って半分の20分でお話いただきました。「どのように速くするか」では、コマンドそのものを早くしようと試されていました。RUNコマンドの中身を早くしようと検討し、GitHubから実行ファイルをcurlまたはwgetでダウンロードするのが遅いことに気づかれたそうです。-vvvコマンドを調べてみたらGitHubはS3でAccept-Ranges:bytesで並列ダウンロードが可能とのこと。そこまで確認された與那城さんは、その問題を解決するrgetコマンドを作られたそうです。curlに比べ約2.5倍も早くダウンロードできるようになったと話されていました。連続するRUN、COPY、ADDを連結するmindコマンドを作成された與那城さん。こちらのコマンドを用いることで実際サイズが小さくなったとのこと。いうのも、Dockerのimageは差分で管理されており、一度でもRUN、COPY、ADDを跨いでしまうとその履歴がimageに差分として残りその分大きくなってしまうとのこと。1つのレイヤーにまとめるのが本当に正しいことかは、並列ダウンロードの恩恵やcacheの有効活用なども鑑みて、きちんと計測してから決めるべきだと話されていました。その他にも、與那城さんはdockerに関わる様々なツールを作られており、非常にdockerに対する情熱を感じるお話でした。エンジニアをされている木村さん。Dynalystでは、秒間200,000〜250,000リクエストを行い、1日で10TB以上のログデータを扱っており、今回はその大量のログデータを綺麗にS3まで運ぶ方法についてお話いただきました。Streamを使い始めるきっかけだったそうです。Functionの候補があったそうですが、S3にオブジェクトを配置するのには工夫が必要だったり、S3のオブジェクトの数が膨大になったりする欠点がありました。Streamには、「Source」と呼ばれるメッセージを吐き出すコンポーネント、「Flow」と呼ばれるSourceからメッセージを受け取り次に送るコンポーネント、「Sink」と呼ばれるメッセージをFlowから受け取るコンポーネントが存在する。このFlowがアップロードした時間ではなく、ログが出力された時間ベースでS3の時間区切りのパーティションで格納されることが、タイトルにもある、「ログ集計に優しいデータフロー」の所以。それだけではなく、集計する時間も半分に減ったとも話されていました。Networkの開発・運用を行い、CTOもされている大谷さん。実際に体験された事例なども踏まえながら、パフォーマンス対策の必要性と、考慮すべき点についてお話いただきました。既存のシステムからトラフィックを変更した数十分後に、広告配信のパフォーマンスが悪化した事例をお話くださいました。問題が発生した時は、スケールアウト・アップして対策したことで、最初の想定より、20倍ほどサーバー費がかかったそうです。その後、直前に行なった「広告キャンペーンの有効化」のコードを確認し、使用していたライブラリのJSONをパースする処理で時間がかかっていたことが原因だと気づかれたようです。3つが大事だとお話されていた大谷さん。その中でも特に、開発者が実験しやすい環境を整え、ツールや手法などのアイデアを試すことができる権限を持つことが大事とのことでした。SMで最近はフロントエンドエンジニアをしている笹原。サービスの両目線から見たパフォーマンスについて話しました。パフォーマンス改善に関しての技術目線では「とにかく速くしたい」や「パフォーマンス改善に時間をくれ!」などを上げられるのに対し、サービス目線での意見としては「〇〇に時間がかかって苦情がくるので改善してほしい」や「効果がわからない速度改善より他をやってほしい」などがあり両者の意見が食い違う中、両者が納得持って進められるやりかたを探したと話していました。そこで取ったやり方が「サービスのKPIとパフォーマンスの因果関係を証明する」というものだったそうです。ヤフーショッピングは、この速度(パフォーマンス)とKPIの相関を証明できた結果、速度改善PJの立ち上げに成功し、速度改善により多くのリソースを割けるようになりました。フロントエンドエンジニアでもある笹原は、時々「そのAPI、速くしても意味ないのに」と思うことがあると話していました。「直列処理で叩いているAPIよりも、非同期で叩いているAPIを改善する場合」や、「非同期で叩いているAPIの中で明らかにボトルネックになっているものがあるのに、それ以外のAPIを改善しようとしている場合」などが上げられるそうです。パフォーマンスを改善する際には、サービス全体の現状を把握し、改善すべき優先度をつけることが大切とのことでした。Backendでは「業務におけるwebサービスのパフォーマンス改善」をテーマとして異なる会社・サービスを提供する5名の方々にそれぞれの視点でお話を頂きましたが、みなさん「計測することの重要性」という点に関しては共通していたのではないかと思われます。パフォーマンス改善を行いたくても、「本当にその改善は必要何だっけ?」と考え、一度踏みとどまる事の重要性どうしても行いたい場合には、「サービスのKPIとパフォーマンスの因果関係」を証明すると実現できる可能性が高くなることなど実際のチューニング技術だけではなく、技術以外のパフォーマンス改善に関わる知見も得ることができたのではないかと思います。Backendは目まぐるしく進化を続ける技術や市場環境との向き合い方について共有することで、新しい知見や発見を得たり技術交流の輪を広げたりすることのできる場として開催していく予定です。JAPAN主催の技術・デザインコミュニティー「Bonfire」では、定期的に勉強会を開催しています。connpassで告知していますので、ぜひご参加ください。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。