2.1

冗長構成を組もう

2.1.3 DB サーバーの冗長化

1

冗長化が必要になるのは Web サーバーなどのフロントサーバーのみではありません。システ

2

ムの根底に関わる重要なユーザー情報などを保存する DB（データベース）サーバーも冗長化を考えるべきサーバーの筆頭です。

3

DB サーバーが故障するとサービスが停止してしまうのはもちろんですが、万一データの破損4があるとサービスを再開できなくなってしまう可能性もあります。そのため、負荷対策や故障による障害などに加えてデータの保護という観点での冗長化が必要になります。

5

DB と一言で言っても、たくさんの種類の DB アプリケーションが存在します。よく使われるRDBMS に加えて NoSQL と呼ばれる比較的新しい形態の DB システムまで様々です。それぞれ得6

意分野や運用方法が異なります。
よく使用されている RDBMS であればレプリケーションという仕組みがあり、サーバーを 2 台

7以上使用して 1 台のマスターと複数台のスレーブで構成します。
この構成ではデータはマスターに書き込まれ、マスターからスレーブに同期されます。

8

データの読み込みはマスター・スレーブのどちらでも可能ですが、書き込みはデータの整合性のためマスターでしかできないようになっています。同期には同期・非同期の 2 通りがあります。

MySQL など RDB の種類によっては、同期を完全同期、非同期を準同期と呼ぶこともあります。
同期（完全同期）●

マスターでの書き込み内容がスレーブでも反映されたことを確認して同期完了とする。

●

同期精度は高く、マスターに障害が起きたときも直前の内容までスレーブに内容が残る。

●

スレーブの同期完了を待つため、マスターの性能が落ちる。

●

仮にマスターが停止してもスレーブを新たにマスターとみなして（昇格させて）動作を継続できる。

非同期（準同期）●

スレーブへの同期は行うが、同期完了の確認をしない。

●

同期に比べマスターのパフォーマンスは高い。

●

同期精度は低く、障害発生時点ではスレーブにデータの同期が間に合っていない可能性がある。

図2.3●同期（完全同期）①書き込み要求②DB データとログへ書き込み⑥書き込み応答
ログファイル⑤マスターへの応答③ログをスレーブへ転送④DB データへ書き込み55

第2章

本番環境を作ろう

図2.4●非同期（準同期）①書き込み要求②DB データとログへ書き込み③書き込み応答
ログファイル④ログをスレーブへ転送⑤DB データへ書き込み

一方で DB としてのパフォーマンスも重要であるため、それぞれのメリット・デメリットを考えながら設計しなければいけません。DB の冗長手法には様々な要素があり、上記はその一例です。DB の特徴をよく知り、構築要件に合わせて設計することが重要です。

2.1.4 リージョンによる分散IDCF クラウドには白河データセンターにある東日本リージョンと北九州データセンターにある西日本リージョンが存在します。どちらも仮想マシンを立てたりファイアウォールやロードバランサーの設定ができたりと、基本的な機能はそれぞれ変わりません。重要なのはリージョン間で物理的に距離が離れているということです。2 つのリージョンを使用してサービス環境そのものを冗長化させておくことで、データセンター全体で機能が停止するような事態が発生してもサービスを継続させることが可能になるからです。
例えば、関東圏全体としての機能が失われるような大災害が発生して復旧作業が困難になったとしても、自動的にサービスが稼働するリージョンが切り替わるようにすることで、リスクを抑えることが可能です。
このような災害に備えたシステムや体制をディザスタリカバリ（Disaster Recovery：DR）と呼びます。DR については「6.4 DR 構成を組もう」にてまた詳しく説明します。
図2.5●リージョン分散
広域負荷分散Backup

西日本リージョン

56

Active東日本リージョン6.3

超高速な DB サーバーを作ろう

メモリのサイズや、ディスクのサイズ、ioMemory の有無やタイプを選べるので、コストが大1きいハイスペックなサーバーのコストの最適化を図ることが可能です。
一方で、ハードウェア専有タイプ仮想マシンと比較して以下の注意が必要です。
●

利用には書面でのお申し込みが必要です（クレジットカードでのお支払いはできません）●

利用開始までに納期がかかります（通常翌 2 営業日）●

最低利用期間は 1 ヶ月となります●

1 つの追加ネットワークにしか接続できません（追加ネットワークの費用も必要です）

2345

例えば、仮想マシンとベアメタルサーバーは次の図の構成になります。
図6.23●各タイプの仮想マシンとベアメタルサーバーのネットワーク構成

6

インターネット78

標準ネットワーク
冗長 2Gbps

冗長 5Gbps

HA 機能搭載タイプ VM

ハードウェア専有タイプ VM

冗長 2Gbps

冗長 2Gbps

1Gbps×2
ベアメタルサーバー

追加ネットワーク

5 ではなく 2 に訂正

以上のように、ベアメタルサーバーはハイスペックかつコスト最適化が可能なため、あらかじめハイスペックが必要とわかっていて使い続ける用途ではベアメタルサーバーを選択し、急なアクセス増時のスケールアウトの対応や、将来的に台数を減らす可能性がある部分では、ハードウェア専有タイプ仮想マシンを選択するのが最適です。

6.3.5 MySQL のチューニング
ここまで見てきたとおり、ハードウェア専有タイプ仮想マシンや ioMemory を搭載したベア
メタルサーバーでは、大量の CPU、メモリと高速なディスク I/O により、高速なデータベースとして利用されることが多いです。高速なディスク I/O を備えているサーバーを利用するので、I/O 部分をチューニングすることでより効果的に活用することができます。ここでは、MySQL
innodb の I/O チューニングについて紹介します。
MySQL 5.5 系 /5.6 系では、my.cnf の [mysqld] グループに以下を追加します。

201

8.4

アドテクサービスの構成例

8.4.2 課題 : ネットワークのコスト

1

上記のように、アドテクにおけるフロント系システムは大量のトランザクションやトラフィッ

2クが発生しますので、クラウドを利用する際に従量課金のコストが非常に高くついてしまうケースがあります。

3

IDCF クラウドであればネットワーク転送量が GB あたり 10 円、前出のコンテンツキャッシュサービス（CDN）を利用すれば GB あたり 9 円ですので、非常に安価にリクエストの受付やコン4テンツの配信が可能です。なお、リクエストあたりの従量課金もありません。

5

事例として Web でも紹介しておりますが、バリューコマース様にはアドネットワークサービ
スで、コンテンツキャッシュサービスをご利用頂いております。

6https://www.idcf.jp/cloud/cache/

7

また、データセンターのような回線プランを定額料金で提供することもできるので、コスト削減に加えて予算化のしやすさも強みです。

88.4.3 課題 : データベースの処理性能
IDCF クラウドであれば、バックエンドにオールフラッシュのストレージを使用しているため、仮想マシンのディスク I/O が非常に高速で、業界で利用実績の多い Aerospike（http://www.

aerospike.com）の利用にも最適です。2014 年にオープンソース化された Aerospike は、SSDに最適化されたインメモリ高パフォーマンス NoSQL データベース・KVS であり、高速性・スケーラビリティ・高可用性が特徴です。現在、IDCF クラウド上でテンプレートを準備しています。
また、通常の RDB システムを構築する際にはハードウェア専有タイプやベアメタルサーバーという、ioMemory を専有利用可能な仮想サーバーのオプションも用意していますので、これを利用することで RDB のチューニングに頼らず、インフラのスペックで大量データに対応することができます。

8.4.4 課題 : Hadoop 運用
上記のとおり、大量のインプレッションログやユーザーデータを格納し、定期的にバッチ処理を行うため、Hadoop を利用している利用者が多いです。その際、ストレージ容量の確保やバージョンアップ、性能維持や障害時の対応など、Hadoop の運用がボトルネックになることもよくあります。

IDC フロンティアの提供サービスで「Yahoo! ビッグデータインサイト」というサービスがあり、月額定額で大量のログデータの保持、分析ができるサービスになっています（150 億レコードまで保持可能で、有償オプションでレコード数を無制限に拡張可能）。

Yahoo! ビッグデータインサイトを利用することで運用負荷を大きく下げられます。
Yahoo! ビッグデータインサイト
http://www.idcf.jp/bigdata/

317