クラウドで実現する大規模 Web プラットフォーム

クラウドで実現する
大規模 Web プラットフォーム
佐藤慎太郎＊
渡辺善三＊
青木勇太＊
吉川晃平＊
The Large-scale Web platform based on cloud computing
要
旨
今日の企業ポータルサイトは様々なサービスを提供すると
ビスを利用し，数十ドメインの Web システムからなる企業
ともに，サービス障害情報や災害情報など緊急性の高い情報
ポータルサイトの集約と，それによる企業ポータルサイト
を公開しており，社会的に重要性が高いシステムとなってい
システムの共通基盤化を行った。Web プラットフォームは多
る。更に，近年スマートフォンの普及やモバイル回線の高速
層化したキャッシュ機構を駆使して，巨大なリクエストに
化による携帯端末向けコンテンツの大容量化が進み，またソ
対して安定かつ高速な応答を返す仕組みとしている。また
ーシャルネットワークサービスの普及により情報がリアル
遠隔サイトに BCP(Business Continuity Planning)環境を構
タイムに共有されることで，短時間にアクセスが集中し，巨
築し，大規模災害対策を実現した。企業ポータルサイトシ
大トラフィックが頻発する傾向にあるが，そのような場合で
ステムの開発においては，本システムを利用する多数のス
も企業ポータルサイトには，安定して高速に応答できること
テークホルダと密に連携し，システム運用フローの再定義
が求められている。このような背景のなか，三菱電機インフ
や，性能対策の策定について PDCA(Plan-Do-Check-Act)サイ
ォメーションシステムズ（株）（MDIS）は，プライベートク
クルを実施することで，個々の課題を解決し，2013 年 3 月
ラウド技術と SaaS(Software as a Service)型クラウドサー
よりサービスを開始している。
大規模 Web プラットフォームの構築事例
企業 Web システムプラットフォームを仮想サーバ上に構築した。本システムは数十ドメインを収容し，多様なコンテンツベンダが複数の CMS(Content
Management System)を使用しコンテンツの開発と公開を行っている。また商用サイトと遠隔サイトがあり各種データを遠隔サイトに同期する構成とな
っている。遠隔サイトでは同期したデータを利用して BCP 環境と検証環境を実現している。
*三菱電機インフォメーションシステムズ（株）
１．ま
え
が
サービスを利用することにより，ウェブサイトのコンテンツ
き
を世界中の ASP(Application Service Provider)型 Web サー
企業の Web ポータルシステムでは，アクセス集中に対して，バにキャッシュし，クライアントからのアクセスを分散させ
安定かつ高速に応答することが求められる。また近年サービることで，帯域を消費するコンテンツにアクセスが集中した
スの重要性が増しており，大規模災害時の事業継続性が求め
場合でも安定して高速に応答することができる。ただし，CDN
られる。これらの課題を解決するため，プライベートクラウ
はコンテンツキャッシュの保持時間が非常に長いため，コン
ド技術と SaaS 型クラウドサービスを活用し，Web プラットフ
テンツ変更後にキャッシュが更新されず古いデータが表示
ォームを構築した。本稿では Web プラットフォーム構築にお
されてしまうことがある。そこで本システムではコンテンツ
けるクラウド技術利用上のポイントを述べる。
更新時に自動で CDN へキャッシュクリアを指示する機能を独
２．大規模 Web プラットフォームの要件
システム構築にあたり，大規模 Web プラットフォームとし
て必要な要件を以下の通り定義した(表 1)。
表1
大規模 Web プラットフォームの要件
項目
説明
要件
応答性能
トラフィックが非常
アクセス集中時(条件:
に多いが，アクセス
2000PV/sec ， 5Gbps) に
集中時も安定かつ
以下を満たすこと
高速に応答できる
・全リクエスト正常応答
必要がある
・応答時間：数十 m Sec
システム
社会的に重要性が
商用サイト災害時に以下
可用性
高く(災害情報の提
を満たすこと
供等)、災害時にサ
・コンテンツデータを消失
ービス継続が必要
しないこと
である
・商用サイトでサービス停
止した時にも，サービス
を継続できること
システム
サイト運用者，コン
・利用者がアクセス可能
利用ユー
テンツベンダ等，多
なコンテンツデータ，機
ザ管理
岐に渡る関係者が
能を制限できること
利用する
・利用者の変更，権限設
定を管理できること
３．大規模 Web プラットフォームのアーキテクチャ
強固なインフラ基盤構築に向けて，大規模 Web プラットフ
ォームの要件を満足するために，本システムで採用した対応
策，アーキテクチャを，以下で紹介する。
3.1
3.1.1
応答性能対策
キャッシュを利用した性能対策
常時多数のリクエストに対応するため，以下の示すように
多段化したコンテンツキャッシュの仕組みを作った。アクセ
スするデバイス毎，コンテンツの内容毎に最適なキャッシュ
を利用することで高速応答を実現している。
(1)
SaaS 型クラウドサービスの利用
画像や映像等，サイズが大きいコンテンツは帯域を圧迫す
る。対策として SaaS 型クラウドサービスである外部 CDN
（Contents Delivery Network）サービスを利用した。CDN
自に開発し，常に最新のデータが表示される仕組みを構築し
た。
(2)
ロードバランサのコンテンツキャッシュ機能の利用
CDN を利用しないドメインでは，ロードバランサのコンテ
ンツキャッシュ応答機能を利用することとした。静的コンテ
ンツへのリクエストの大部分をロードバランサで応答させ
ることで，Web サーバの負荷を大幅に軽減できる。デバイス
毎に異なるデザインのページは，User-Agent 毎に異なるキャ
ッシュを保持・応答することで，デバイス毎に最適なコンテ
ンツの高速応答を実現している。昨今増えているユーザ毎に
異なるパーソナライズされたページは，ページ内の静的コン
テンツはキャッシュで応答し，ユーザ固有に生成する動的コ
ンテンツは Ajax(Asynchronous JavaScript + XML)技術を応
用し，クライアント(ブラウザ)側で非同期にアクセスさせる
ことで，高速に応答している。
(3)
オンメモリ KVS の利用
DB データの参照は複数の参照用 DB サーバで処理を分散し
ている。しかし，DB データの更新は 1 台の DB サーバで行う
必要があるため，DB データの更新が発生すると応答性能が大
きく低下する。そこでセッション管理を要する Web サイトで
は，セッション管理のトランザクション処理に DB を使用せ
ず，高速なオンメモリ KVS(Key-Value Store)を利用すること
で，DB データの更新処理を回避し高速化している。
(4)
ストレージキャッシュの利用
仮想化基盤システムでは一般的にコンテンツデータ，DB
データ，仮想サーバのディスクイメージ等を共有ストレージ
上に配置するため，共有ストレージの I/O がボトルネックと
なる。本システムでは共有ストレージに高速なフラッシュデ
バイスを搭載して二次キャッシュとして利用することで，デ
ィスクアクセス性能を向上させ，仮想化基盤全体のパフォー
マンスの改善を図っている。
3.1.2
性能対策での PDCA の取り組み
画像や映像等のリッチコンテンツは転送時間が長く，イン
タラクティブなコンテンツを多用した Web ページはシステム
への負荷が高いという課題がある。これらの課題はコンテン
ツの実装による影響が大きいため，コンテンツベンダと連携
し性能対策の以下の PDCA サイクル(図 1)を実施した。
・Web サイトの要件定義時から，クライアント種別(PC，
スマートフォン等)とその比率，及びコンテンツ種別(静
的，動的等)からトラフィックのモデル化を行い，それ
を基にリソースのサイジングを行う(Plan)。
・システム構築後，モデルトラフィックで負荷をかけ性能
試験を実施する(Do)。
・試験結果を評価，ボトルネックを調査する(Check)
・調査結果をもとにインフラ及びコンテンツの性能対策
を実施する(Act)。
本システムではプロトタイプ作成時と完成時に PDCA
を回し，プラットフォームとコンテンツでそれぞれ最適な
性能対策を実施することで，ユーザエクスペリエンスを低
下させず高速応答を実現した。PDCA サイクルで得られた性
能対策のノウハウはコンテンツ作成ガイドラインとして整
理し，ステークホルダ間で共有して，システムの安定稼働
のための対策を講じている。
図 2 サイト間データ同期とデータの利用方法
3.2.2
遠隔バックアップの実現
大規模 Web プラットフォームにおいては，様々な障害やオ
ペレーションミスによるデータ消失に備えて，商用サイト内
だけでなくシステム外部にバックアップデータを保管して
おくことが重要である。本システムでは商用サイトから遠隔
サイトに同期したコンテンツデータ，仮想サーバイメージデ
ータをバックアップデータとして利用することで，商用サイ
トでデータを消失した場合に，遠隔サイトのバックアップか
らのデータの復旧を可能とした。
図 1 性能対策での PDCA
3.2
3.2.3
システム可用性対策
BCP 環境の実現
本システムでは，商用サイトで大規模災害時のサービス障 (1) BCP 環境の要件
害対策として，サーバ仮想化技術を利用し，遠隔サイトには
BCP 環境の構築にあたり，Web プラットフォームの BCP 環
BCP 環境を構築した。また遠隔サイトへ同期した各種データ境として必要な要件を表３に示す通り定義した。
表 3 BCP 環境の要件
を利用し，コンテンツデータ消失対策として遠隔バックアッ
プを実現し，また検証環境を構築した(表 2)。以下では，遠
隔サイトの各環境の構築，機能等について述べる。
要件
目標値
データ鮮度
公開中，編集中のコンテンツデータがリ
表 2 本システムが備える環境
名称
説明
商用環境
通常時にサービスを提供する
アルタイムに同期されること
ロケーション
商用サイト
環境
BCP 環境
災害発生時に切り替えてサー
コンテンツやインフラの動作検
遠隔サイト
被災時の切り替えを 1 オペレーションで
実施できること
次に BCP 環境の要件を満たすために必要な各種データの最
遠隔サイト
新化タイミングの要件を表４に示す通り定義した。
証を行う環境
3.2.1
商用環境と同じ機能(コンテンツ公開，
編集，ユーザ管理)を提供できること
運用操作の容易性
ビスを継続提供する環境
検証環境
機能同一性
システム全体でのデータ同期の仕組み
遠隔サイトでのコンテンツデータの保存，及び BCP 環境，
表 4 データの最新化タイミングの要件
データ種類
最新化タイミング要件
コンテンツデータ，
コンテンツデータ，DB データは商用環
検証環境の実現のため，商用サイトと遠隔サイト間でシステ
DB データ
境と同期されること
ムが利用する各種データをリアルタイムに同期する設計と
仮想サーバイメー
商用環境の変更の都度，最新化するこ
した。データの同期は共有ストレージの遠隔同期機能と，各
ジデータ
と(更新頻度：多い)
種ミドルウェアのレプリケーション機能を利用し実現した
ネットワーク設定，
商用環境の変更の都度，最新化するこ
(図 2) 。
ハードウェア設定
と(更新頻度：少ない)
上記の要件を満たす BCP 環境と，災害発生時の切替運用に
ーブとして同期しているため，BCP 環境の DB サーバは書き込
ついては，サイト運用者と十分に検討を行い決定した。
み不可状態になっている。切替時には DB サーバを書き込み
(2) BCP 環境の構築
可能状態に変更し，BCP 環境でデータが更新できるようにす
BCP 環境の構築にあたり，パッケージ製品の採用を検討し
たが，前述した Web プラットフォームに求められる様々な要
件を満たすことができなかったため，独自に BCP 環境を構築
る。
①′ルーティング切替え操作
ルーティング変更(①)は BGP-4 プロトコル(*1) によりシス
することとした。
テム上位のルーターのルーティングテーブルを商用環境か
①BCP 環境用コンテンツ設計
ら BCP 環境に瞬時に切り替える方式とした。これにより，短
BCP 環境で使用するコンテンツデータは，商用環境と同じ
時間での BCP 切替を実現した。本システムでは，あらかじめ
最新のものである必要がある。前述の，システム全体のデー
商用環境，BCP 環境の両方の上位ルータに設定を組み込んで
タ同期の仕組みにより，常に商用環境と同じデータが利用で
おくことで，災害発生時に簡単な操作で切替えを可能とした。
きる設計とした。
②′DB サーバの構成変更
②BCP 環境用仮想サーバ設計
BCP 環境用の仮想サーバは，商用の仮想サーバを元にホス
DB サーバの構成変更(②)は，切替操作ミスの防止及び作業
時間の短縮のため，BCP 切替プログラムを開発し，1 オペレ
ト名，IP アドレス等のネットワーク設定を拠点に合わせて変
ーションでの切替を実現した。
更して生成する設計とした。サービスに利用するネットワークの
3.2.4
検証環境の構築
IP アドレスは，コンテンツやプログラム内に埋め込まれており，変
BCP 環境は平常時は利用されないため，遠隔サイトの HW
更すると動作に影響するため，保守経路の IP アドレス(監視用)の
リソースは遊休状態となっている。遠隔サイトの HW リソー
み変更し，それ以外のネットワークセグメントは商用環境と同じ IP
スを有効活用するため，遠隔サイト上に検証環境を構築し，
アドレスを使用する設計とした。
平常時は検証環境として活用する設計とした。検証環境の構
③短時間での BCP 環境用仮想サーバ構築の実現
築は，前述の BCP 環境構築機能と同様に，商用環境の仮想サ
BCP 環境用仮想サーバの構築は，遠隔サイトに同期した商
用環境の仮想サーバイメージを 1 台ずつ BCP 環境用に設定変
ーバイメージを検証環境用にバッチ処理で変換する方法で
行い，検証環境構築作業を効率化した。
更を行う。しかし仮想サーバの台数が多いため，手動で実施 3.3
システム利用ユーザの管理
した場合に時間がかかる，また設定ミスが発生するリスクが
本システムでは多数のコンテンツベンダ等が CMS を利用し
あった。そこで仮想サーバの設定変更をバッチ処理で行う機
コンテンツを作成しているが，セキュリティ/情報漏えいの
能を開発し，短時間に多数の BCP 環境用仮想サーバの構築を
観点から，利用者毎にアクセス可能なコンテンツデータを厳
可能とした。
密に分離する必要がある。そのために，本システムでは
④BCP コンテンツ確認，リハーサル訓練
LDAP(Lightweight Directory Access Protocol)をベースに
BCP 環境の上位ネットワーク機器には，サービス用のグロ
アカウント管理機能を開発した。本機能により，利用者毎の
ーバル IP アドレスとは別に，コンテンツ動作確認用の IP ア
ロール設定(権限管理)を実現するとともに，コンテンツ作成
ドレスの設定を行った。本設定により，平常時に BCP 切替を
機能に関する各認証(リモートログイン認証，CMS ログイン認
行うことなく BCP 環境のコンテンツ動作確認や，BCP を想定
証等)の一元管理を実現している。
したリハーサル訓練を可能とした。
４．む
す
び
(3) BCP 切替の運用
商用環境で災害が発生しサイト運営が困難と判断された場合，
BCP 環境への切替を行うことによりサイト運営を継続する。
平常時は BCP 環境は以下①，②の状態でスタンバイ状態を
本システムは 2013 年 3 月よりサービスを開始し，その後
安定してサービスを提供している。Web ポータルサイトでは，
常に新しいコンテンツやサービスの追加が行われており，応
保つ。BCP 切替が必要となった際には①′②′のように設定
答性能の安定化と迅速なサービス基盤の拡張が求められて
を変更する運用としている。
いる。MDIS では，引き続きクラウド技術に積極的に取り組み，
①ルーターの設定
Web プラットフォームの高機能化を図り，また他システムへ
平常時は，システム上位のルーターに商用環境に向けてル
ーティングが設定されている。切替時には，上位ルーターの
の展開を進めることで，更なるインフラ基盤共通化を目指し
ていく。
ルーティングテーブルを BCP 環境に振り向けることで IP レ
ベルで拠点間切り替えを実現する。
②DB サーバの構成
平常時は DB サーバは商用環境がマスター，BCP 環境がスレ
(*1) BGP-4 は, インターネット・バックボーン上でルーティング
テーブル情報を交換する際に用いる経路制御プロトコル。

Download Report