現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。resumptionを使ってみた話あっどうも、社員Mです。技術についてアツい紹介がありました。私は、このあたりの技術を片っ端から人柱することを専門に担当しています。本日はその結果について簡単にご紹介できればと思います。弊社で謎の人物キャラがはやるのは前CTOの明石さんの影響ということにしておきます(笑)。はじめにスマートフォンが利用するモバイルネットワークは応答時間が大きくなる傾向があり、ユーザー体験を向上させていくためには、応答時間とパケットの往復回数に着目した技術的な工夫が必要だと感じております。resumptionを利用することで、TLS接続においてユーザーとサーバーとのパケットの往復回数を減らすことができ、高速化が期待できるという話がありましたので今回取り組んでみました。resumptionの前に取り組むことユーザーとサーバーの通信コネクションを1回の通信ごとに切断することは応答時間の大きなネットワークにおいては非効率です。HTTP1.xのkeep-aliveなどを活用しユーザーとサーバーのコネクションを数秒から数十秒接続を維持することが重要です。ServerやNginxといったモダンで同時接続に強いソフトウエアではこの設定を行っても問題にならないので必ず設定を行いましょう。httpdは、アプリケーションを実装するコンテナとしてはとても便利なのですが、同時接続の数だけプロセスやスレッドを消費するモデルのため、膨大な接続を処理するEdgeとしては非効率といわざるをえないでしょう。resumptionを導入することで、keep-aliveなどによるコネクションの持続でカバーできないような再接続のケースに対して効果が期待できると考えました。Cacheによるセッション再開の仕組みについて簡単に説明します。システム構成2つの拠点のデータセンターにそれぞれロードバランサーを2セットづつ配置し、セッション情報をデータセンター単位で共有する構成としました。Ticketによるセッション再開を利用しないものとします。効果TLSの接続の40%から45%に対してセッションを再開することができました。キャッシュの共有範囲を小さくしたらどうなるか上記の構成は、セッションを再開するために必要な情報を共有するキャッシュシステムがスケールアウトするという前提に基づきますが、大規模に利用する場合は、これらのサーバーは大量の接続を処理するため、キャッシュシステムやネットワークトラフィックについても考慮が必要です。それらのシステムがスケールアウトしなくなる状況が発生した場合への対応も検討する必要があります。仮にこのような状況が発生した場合には、セッション情報を共有する範囲をLBの単位といった小さな単位にしていく方法が考えられますが、このアプローチはセッション再開する確率を低下させる可能性があります。ブラウザーが再接続する際にDNSに問い合わせを行い、返却されたIPアドレスが前回接続したロードバランサのIPアドレスと異なる可能性があるためです。私の所属するチームの別のシステムにおいて、セッションの共有範囲を小さくした上でテストを行ったところ、TLSの接続の20%しかセッションを再開することしかできませんでした。このような状況が発生した場合、キャッシュシステムをスケールアウトするように作り直すことも大切ですが、データセンターが3つ、4つと増え続けた場合には同様に再開率を低下させる可能性があり完璧ではありません。Ticketによる再開を組み合わせて利用していく必要があるのではないかと考えております。将来的にDNSを利用した広域分散が実現できないか調査と検討をしていきたいと思っております。Staplingといった技術を既に利用しております。Resumptionの効果の向上やHTTP/2の導入を本格的に進めて行きたいと考えております。これらの取り組みについて、次の機会にご紹介できれば幸いです。ありがとうございました。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。