はじめに

様々なシステムを構築する際、そのシステムを稼働させるインフラ環境を構築する必要がありますが、ここ数年で、だいぶ作り方が変わってきました。
現在(2019年)は、

Amazon Web Services(AWS)
Google Cloud Platform(GCP)
Azure(MicroSoft)

などのクラウドサービスを利用して構築することが主流となってきており、
各クラウドから提供しているWebコンソール上でマウスを動かすだけで大抵の作業が完了します。
これに対し、ひと昔前までは必要なソフトウェアはすべて自分達でインストール・設定する必要がありました。
尚、本記事ですが「今は簡単だけど昔は大変だった」と武勇伝的なことを伝えたいのではなく、現在の各クラウドから提供されている様々な技術(サービス)を簡単に利用することができる状況ですが、それらの技術(サービス)の裏では、下記に書かれているような様々な技術がふんだんに利用されています。

「技術に対する好奇心」は、技術者にとって最も必要な要素だと思っていますので、各サービスを利用する際、その裏ではどのような技術が使われているのか？
など、少しでも考えるきっかけになっていただければと思います。
で、今回は、
　- ロードバランサ(LB)
　- DBの冗長化
の、ひと昔前の構築方法について紹介します。
※いづれも各クラウドでは、Webコンソール上で、数クリックするだけで実現可能。

#ロードバランサ(LB)を構築する
※ロードバランサは、いろいろな用途で利用可能ですが、ここではWEBロードバランサを前提として記述します。

LBに対する要求
- ①分散処理を実現する
- ②LBの高可用性
①分散処理を実現する
Linuxサーバで負荷分散を実現するもっともポピュラーな方法である「LVS(LinuxVirtualServer)」を利用します。
LVSは、IPVS(IP Virtual Server)とipvsadmユーティリティから構成されていて、Layer4での負荷分散を実現します。
ただし、LVSにはバランス先のWEBサーバの状態を監視する機能が備わっていないため、「Keepalived」というソフトウェアと組み合わせて、L4負荷分散を実現します。
②LBの高可用性を実現する
上記①の対応で、LBまで来たHTTPリクエストを、LB配下にある複数のWebサーバにバランスすることができましたが、
この状態では、もしLBサーバが不能な状態に陥った場合、そのWEBシステムに接続できなくなってしまします。いわゆる単一障害です。
そこで、単一障害を回避するために「LBの高可能性」の実現です。
もし、LBが不能となった場合、その変わりを担うLB(Standby機)を予め準備しておきます。
そして、VRRPというプロトコルを利用して、LB(Active)が正常稼働しているかどうかを都度チェックし、LB(Active)の異常を検知した場合、瞬時にstandby機をActiveにフェールオーバー(昇格)するように設定します。

これで、高可用性なLBサーバの構築が完了となります。

DBの冗長化

DBにはRDBMSやNoSQLなど様々な種類がありますが、今回はRDBMSであるMYSQLを例に話します。
システム仕様にもよりますが、DBは負荷上昇しやすいインフラパーツのため

・適切なSQLでデータの登録・取得を行う
・格納するデータ容量は可能な限り少なくする(DBデータ容量はディスクだけではなくメモリ使用量にも大きく影響するため)
・適切なメモリの割り当てを行う(my.cnf設定)
・参照用のスレーブDB(リードレプリカ)を作成し、データ参照による負荷を分散する

などを丁寧に行う必要があります。
また、DBはシステムの生命線でもあるため、DBが不能となった場合を考慮した仕組み・構成にする必要があります。
例えば、

・マスターDB×1台
・スレーブDB×1台

という構成に対して、冗長化構成を考える場合ですが
スレーブDBの冗長化は、スレーブDBを複数台構成にするだけで対応ができます。
※MYSQLで、複数のスレーブDBを作成するのは、MYSQLの標準機能で実現可能
※複数台構成のスレーブDBのうち１つが不能となった場合、そのDBをシステムから切り離す(参照しないようにする)必要があり、その場合はLBやHaProxyなどを利用することになりますが今回は割愛します。

それに対してマスターDBは、スレーブDBのように簡単に冗長化構成にすることはできません。
まず、ネットワークを通じてハードディスク(ブロックデバイス)をリアルタイムに複製(同時複製)することができる「DRBD」というソフトウェアを利用します。
MYSQLに登録したデータは、そのDBサーバのDISKに保存されますので、そのDISKに保存されたDBデータをDRBDを利用して、他サーバ(マスターDB(standby))にリアルタイムで同期(複製)します。
次に、マスタDB(Active)が不能になった場合、それを検知して、あらかじめデータ同期しておいたマスタDB(Standby)をActiveにフェールオーバ(昇格)させる必要があります。
それを実現させるためには、まず「Corosync」を利用してActive機の異常を検知し、「Pacemaker」がフェールオーバー(Standby機をActive機に昇格させる)を行います。
これで、高可用性のDBの構築が完了となります。

最後に

上記に記述した内容ですが、まずは概要を知っていただきたいと思って記述した文章となるため、
技術的な詳細部分についてかなり省略していたり、狭義の意味で間違っている記述もあると思いますがご容赦ください。
また、本記事ですが「ひと昔前」とは書きましたが、現在でもお客様都合でクラウド利用不可でオンプレサーバ(物理サーバ)で構築する必要がある場合もありますので、上記した技術は廃れた技術ではなく、現在でも世の中の多くのシステムで利用されています。