紹介する論文は、USENIXのLISA '12にて発表された「What Your CDN Won't Tell You: Optimizing a News Website for Speed and Stability」です。CDNを用いるにあたり、どのような「変数」を気にする事が大切なのか、そしてチューニングにあたってどこに目を付けることが大切なのかを知る事ができる論文です。特に、メディアサイトを運用されている方には参考になるのではないでしょうか。

※ちなみに、この論文の執筆者であるJulian Dunnさんは、現在Chefで有名なOpscodeにお勤めのようです。

※誤訳やより良い解釈がある等ありましたら、twitterの @koemu までお知らせください。

概要

カナダ最大のニュースサイト「Canadian Broadcasting Corporation」(CBC)における、CDNを最適化する手法を紹介します。本サイトは100万UU/日以上をさばいてます。CDNにはAkamaiのAqua Platform(旧EdgeSuite)を用いていますが、話の内容はたいていのCDNで適用できる事です。

※斎藤注: Amazon CloudFrontなど、様々なCDNでもこの考えを利用できそうですね！

はじめに

CDNは、この10年でよく使われるようになりました。インターネットユーザが爆発的に増え、それらを独自のインフラで捌くための投資は、もはや非現実的です。

この事は今日のオンラインメディアビジネスでも言えます。そして、配信するニュースの内容により、トラフィックは大きく乱れるものです。例えば、9.11、地震、津波、米国大統領選挙などです。これらが、10ないし100倍のスパイクを引き起こす可能性があります。この1つや2つの主要ニュースの配信のためににCDNは不可欠なものとなります。

多くのインターネットシステムの管理者は、既にCDNの技術的な設計に精通しています。また、多くのユーザがコンテンツの同じ部分にアクセスする事を前提に動作させるため、分散キャッシュとして機能する事ができます。

実際にはCDNは静的なコンテンツには最も有用です。ただ、過去10年に渡るインターネット環境の高速化と高レスポンス化は、CDNの配信速度の優位性を減らしました。とはいえ、メディア企業のためには、大きなトラフィックの変動に対してCDNは依然有用であります。

※斎藤注: CDNは、コンピューティングパワーが上がったので必要性こそ減ったものの、(後述する)急なトラフィック変動に対してはまだまだ有効ですよね、というお話です。

CDNをチューニングするってどういう事？

CDNのチューニングとは、ビジネス要求と技術要求の深い理解を必要とする洗練されたプロセスです。それは、コンテンツポリシーを確立し、技術的パラメータ(TTL(Time To Live - 有効期限)等)を設定する事以上のものです。CBCでは、はじめにこの点の問題を犯してしまったのです。チューニングの前に、CDNのインフラの詳細を理解する事が重要です。調べる価値がある事柄で、そのうちのいくつかは次の通りです。これらは、この後にルールを決める際に重要となってきます。

• CDNがオリジンサーバからコンテンツを取得している時のアーキテクチャ。
• サイト上でにおける、パーソナライゼーションとコンテンツの量。
• コンテンツの更新頻度。
• ユーザのアクセスパターン。
• コスト・コンテンツの鮮度・信頼性・複雑性等、ビジネスの要求を支配する事柄。

CDNのチューニングに際し、重要となるパラメータは次の通りです。

• TTL, 鮮度のチェックの周期
• オリジンサーバとの鮮度の保持の差異に対するトレードオフ
• 帯域幅とそのコスト
• CDNを用いるためのHTTPの最適化

※斎藤注: いたずらにCDN・オリジンサーバのパラメータをいじるのではなく、オリジンサーバの仕組み、ひいてはコンテンツの特性を充分に理解する事で、一つ一つのパラメータを定義する際に「理由付け」できる状況を作る事が大切だよ、という話だと理解しました。

メディアサイトにおけるコンテンツアクセスの傾向

CBCにおいて、アクセスのスパイクしている様子(ホイットニーヒューストンが亡くなった2012/02/11のグラフ)を図1に示します。

(図1: アクセスのスパイクの例)

斎藤注: 図1のグラフが、「はじめに」で示されていた、1つのニュースで100倍ものアクセス増を引き起こす事例の一つです。計測の最後(ほぼ平常時)の時点で約700Mbpsですが、ホイットニーのニュースが流れた直後は約14Gbpsと、約20倍にもなっています。突然の出来事のために、普段使わないサーバを数多く用意するのは、現実的ではないことがわかります。 また、これは斎藤の主観ですが、TwitterやFacebookなどで速報がより素早く(いわゆる)「拡散」することで、よりアクセスが集中しやすくなっているのではと思います。

その上で、コンテンツアクセスの傾向は大きく2つの要点があります。

• コンテンツは、24時間を過ぎるとほぼ更新されない。

速報は24時間以内の更新がほとんどです。その後は、その話に続く新しい記事が配信されます。また、月曜日に事件が起き、金曜日にその犯人が逮捕されるような場合、関連した記事同士でアクセスがなされ、バースト性が高まります。

斎藤注: 日本ですと、「XX首相 辞任」という速報が流れ、次の日に「〇〇党 政権奪取に動く」というニュースが続く、そんなイメージでは無いでしょうか。

• コンテンツの更新がユーザのアクセスのペースに間に合わない

古い記事が出てしまう場合があるのです。

斎藤注: CDNのTTLのお話です。速報は更新頻度が高いため、通常の記事と違い、TTLを短くする事が求められます。

メディアでのコンテンツ配信の要件

次に挙げるいくつか、そして時として矛盾する要件をバランスさせていきます。

• コンテンツの鮮度
• 安定性と信頼性
• (システムの)複雑さを最小限にする
• コスト抑制

複雑さを最小限にする理由の一つとして、ジュニアスタッフ(恐らく、上級のエンジニアでなくともという意味でしょう)でも、容易に設定変更に関与できる状況にしておく事が大切です。

コストは、アラブの春や3.11などの大きなイベントが発生した場合でも、CDN利用料を予算内で抑えられるように注視して管理する事が不可欠です。

※斎藤注: シンプルな構成、かつ容易に設定変更を行えるようにすることで、高負荷になったときにでもスタッフの誰もが対処できることが重要だと筆者は述べています。高負荷になる度に、あなたの携帯が鳴って対処を迫られたら...たまらないですよね。常にお客様...そして自分自身が安心できるよう施しておくことは、ITインフラを支えるエンジニアの醍醐味かと思っています。

既存のCDNを通じた配信の問題点

1995〜2006年、CBCのサイトはJ2EE(Java 2 Enterprise Edition)アプリ＋DB構成で動いていました。しかし、次の点でフィットしていない仕様でした。

元々、CDNはオリジンサーバの障害に対する保険として運用されていました。しかし、それでは動的なコンテンツはどうにもならなくなります。また、しばしTTLのキャッシュがパージされる前にCDNのキャッシュを更新しろと緊急連絡もありました。この作業には、6万のサーバに影響があるため、対応に15分程かかります。

そこで、オリジンサーバの刷新にあたり、次のような実装をおこないました。WebサーバはApacheとし、コンテンツは静的なHTMLに加えて各画面のパーツ(メニュー等)はSSIによって構成しました。SSIはRuby等に比べて原始的な技術ではありますが、軽量かつ高速、そして高負荷下でもよくスケールし、優れたセキュリティを提供します。ただし、そのためにはCMSを導入する必要があります。これにより、刷新の副作用として記事の作成・編集にはCMSを介さなければ操作できなくなりました。

※斎藤注: J2EE(Tomcat等)のアプリケーションサーバと、Apache、比較してどちらがスケールしやすいかと考えれば、Apacheに軍配が上がるかと思います。ここに、先節の「複雑さを最小限にする」思想が現れていると言えます。 ただ、コンテンツを作成する際にHTMLを手で書く事は、メディアサイトの規模であると現実的ではありません。そこで、CMSの静的ファイルの出力機能(MovableTypeなどにありますよね)を使ってコンテンツ作成の利便性を担保されているようです。同時に、CMSの必要になることを「副作用」と筆者は述べています。

斎藤より: 前半について

前半は、CDNをチューニングするにあたって「ビジネスの特性」と「オリジンサーバの特性」を充分に理解する大切さが述べられていました。当社でもメディアサイトをお預かりしていますが、経験者によって体系的に一つのモデルとしてまとめられている論文を読むと、これまでのことを改めて整理する事ができ、有意義でした。

後半は、肝心のパラメータチューニング、デバッグ方法、さらに著者が計画している今後の活動についての部分が述べられています。

(後半の記事を読む＞＞)

それでは皆様、ごきげんよう。