全日本空輸は，航空チケットのオンライン予約などを受け付けるWebサイトのサービス品質を向上させるべく，コンテンツ・デリバリ・サービスを導入した。きっかけはバーゲン型運賃の「超割」を適用したチケットの発売時に発生するピーク・トラフィック。平常時の100倍以上にも達するトラフィックをさばき，かつ高速レスポンスを維持できるネットワーク・システムを，必要最小限のコストで実現した。

写真1●全日本空輸のWebサイト インターネット経由で航空チケットの予約を受け付けている。空席情報の照会や旅情報などのサービスも提供。チケット予約については，1カ月に1回程度，「超割」の予約も受け付ける。超割の受け付け開始直後は，トラフィックが平常時の100倍にも達する

図1●全日本空輸はWebサイトのアクセスを高速化させるためにCDNを採用した アカマイ・テクノロジーズ・ジャパンの「EdgeSuite」を採用。予約などの処理はバックエンドのメインフレーム上で実行するが，Webページを構成する静的なコンテンツはアカマイのエッジ・サーバー（キャッシュ・サーバー）にキャッシュ。エンドユーザーは，Webページの構成要素のほとんどを最寄りのエッジ・サーバーから取得するため，高レスポンス

　全日本空輸（ANA）は2002年1月，同社Webサイトの品質向上を目指し，いわゆるCDN（コンテンツ・デリバリ・ネットワーク）サービスを導入した（写真1）。アカマイ・テクノロジーズ・ジャパンの「EdgeSuite」である。

　CDNは，Webサイトのレスポンスを高速化するための仕組み。インターネット上にキャッシュ・サーバーを分散配置し，そこにWebコンテンツをキャッシュする。エンドユーザーに対しては，最寄りのキャッシュからコンテンツを提供するため，ネットワークの伝送遅延を低減させ，応答性能を高めやすい。サーバーの負荷を分散させられるメリットもある（図1[拡大表示]）。ANAの場合も，「インターネットに依存するレスポンスのボトルネックを一掃できた」（IT推進室IT基盤担当の川浪 宏之氏）と導入後の評価は上々だ。

「超割」でトラフィックが殺到

　CDNサービスを検討し始めたきっかけは，「超割」の予約を受け付けた際に，Webサイトのレスポンスが極端に劣化したことだった。超割は，「全国のどこからどこへのフライトも1万円」という，期間限定のバーゲン型運賃。特定期間のフライトを対象に適用される料金で，フライトの約2カ月前の一定期間での予約にしか適用されない。この超割によって「アクセス・トラフィックに極端なピーク性が出るようになった」（川浪氏）。この急激なアクセス増が性能劣化を招いたのである。

　超割を適用し始めたのは2000年4月のフライトから。予約受け付けとしては，2000年2月からである。当初からWebサイト上でも予約を受け付けていたが，はじめのうちは，超割の認知度は高くなく，アクセス数が激増するには至っていなかった。

　ところが，超割の販売を繰り返すうちに，発売時にアクセス数が急増する傾向が表れた。2001年7月の時点では，超割チケットの発売開始直後から数時間にわたって，1分当たり5万件ものアクセスを受け付けるようになった。これは「平常トラフィックの100倍以上」（川浪氏）。もともと，夏休みや年末年始を控える時期にはトラフィックが増えていたが，それでも平常時の2～3倍。これが，超割の定着で状況ががらりと変わり，サイト設計の再考を余儀なくされた。

頻繁に繰り返したサイト増強

　同社がWebサイトを開設したのは95年のこと。97年11月にはWebサイト上で航空チケットの予約を受け付けるようにした。システム的には，Webサイト上での予約処理は，CGI（共通ゲートウエイ・インタフェース）スクリプトを介して，バックエンドのメインフレーム上で実行される。ユーザーは，フライト情報や空席状況，運賃をチェックしながら予約できる。このオンライン予約の開始をきっかけに，Webサイトへのアクセス数が急激に伸び始めた。「アクセス数は，毎年，前年の4倍に膨れ上がってしまう状態が続いた」（川浪氏）。

　もちろん，システム面での対策は打ってきた。Webサーバーは，トップ・ページを中心としたコンテンツを配信するサーバーのほか，予約を受け付けるサーバー，空席情報の照会サービスを提供するサーバーなど，機能別に別のマシンを用意。それぞれのサーバーを2台構成にして，ロード・バランサを使って負荷分散させている。

図2●Webサイトの品質向上に向けたこれまでの取り組み Webサイト上で予約受け付けサービスを提供し始めて以来，サーバー・マシン（メインフレームも含む）の増設・増強，アクセス回線の増速とマルチホーミング化などを随時実施してきた。特に負荷が高かったGIFファイル配信部分だけを切り出し，インターネット・データセンターに設置（ホスティング）した専用サーバーから配信する構成をとった

　さらに，アクセス数の伸びにあわせて，システムやネットワークの増強を繰り返してきた。Webサーバーの増設はもちろん，ソケット・リッスン・キューのサイズ（TCPの同時セッション数）や同時に稼働させられるHTTPプロセス数といったパラメータのチューニングを実施。予約処理を実行するメインフレームもCPUを増設し，ソフトをチューニングしてきた。

　もう1つの工夫は，GIFファイルの配信だけを独立させたこと（図2[拡大表示]）。ANAの場合，Webページの構成要素であるGIFファイルがコンテンツ配信の重荷になっていた。トップ・ページだけでも，場合によってはGIFファイルの数が100個以上にもなる。1つひとつの容量は小さいものの，ページ全体としては相当量。アクセス数が増えれば，負荷は飛躍的に増す。写真などを多用した旅情報やアミューズメント情報の影響も大きい。

　そこで，GIFファイルだけを搭載したWebサーバーを，インターネット・データセンターに設置した。HTMLファイルそのものとスクリプト・ファイルはオリジナルのサイトから，Webページ内のイメージ・ファイルはインターネット・データセンターから配信することでトラフィックを分散させ，応答性能を高めた。

　インターネット接続も同様だ。97年11月時点では512kビット/秒の専用線を利用していたが，半年から1年ごとに増速を繰り返した。1.5Mビット/秒，3Mビット/秒（1.5M×2），6Mビット/秒（3M×2），そして現在の12Mビット/秒（6M×2）。途中からは，ISPの異なる2つのアクセス・ポイントを利用したマルチホーミングを実現し，信頼性も向上させている。