これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
こんにちは、おひさしぶりです、もしくははじめまして。津村です。
夏といえば海に山に田舎に、行く所は沢山ありますよね。そしてお子さんの夏休みやご自宅のサーバの負荷も相まって、エアコンの電気代が上がる季節でもあります。
最近では法令の緩和もあり、スマホから制御できるエアコンも発売されてきています。いずれIoTの一環として、DIY感覚でエアコンをコントロールできる日が来るかもしれませんね。
さて、第2回『OSI階層モデルをマスターして、通信を理解しよう！』では、OSI階層モデルで言う所のレイヤー４とレイヤー７に「ロードバランサ」という機器があり、AWSではELB(Elastic Load Balancer)が該当する事を簡単にお伝えしました。今回は、ELBを例にロードバランサについて掘り下げてみたいと思います。
例えば、構築・運用するシステムが、どうしても止まってほしくないサイトである場合や、もしくはサーバ１台ではとても賄うことができない負荷を処理しなければいけない時、ロードバランサを使うことになります。
上記はコラム第１回からの引用ですが、上記でいう「LB1」「LB2」のようにロードバランサを配置し、従来から止まらない（止まりづらい）インフラを作ってきました。
元々はハードウェアアプライアンスでしたが、後にオープンソースのリバースプロキシやL4スイッチ、そして昨今のクラウド化によりELBといったベーシックなロードバランサが標準提供されるケースも増えました。
引用元：Cisco Load Director 400Series
http://www.cisco.com/c/en/us/support/routers/localdirector-400-series/tsd-products-support-eol-series-home.html
当初、ロードバランジングにはDNSラウンドロビンといった方法が採られており、DNSの名前解決におけるランダム性に委ねられていました。その為厳密には均等に配下のサーバへ負荷が割り振られる事が無く、偏りがありました。
2000年過ぎ(上記製品は2002年発売)にロードバランサのアプライアンス機器が発売され、徐々に市場へ広がっていきました。現在ではルータ・スイッチがメインのCisco Systemsが、当時はロードバランサも開発・発売していました。
その他さまざまなアプライアンス機器がありますが、大規模運用の環境をメインに、例えば以下のような機器が使われています。
また、オープンソースソフトウェアでもLayer7スイッチ(リバースプロキシ)を中心にロードバランサは存在し、無償で構築・運用することができます。
Poundは古くからSSLの終端に、Nginxは昨今では高速なウェブサーバ・キャッシュサーバとしても使用され、またいずれも信頼性が向上してきており、実際に実用に耐えられえています。
またVarnishはMySQLの負荷分散にも使用できるようになり、従来アプリケーション側で処理しなければいけなかった部分をインフラ側で処理できるようになりつつあります。
さて、先に挙げた商用ロードバランサ製品は、アプライアンス装置として購入するととても高価な製品です。安くて数百万円～、F5ネットワークス VIPRIONに至っては冗長構成で構築すると数億円程度は掛かります。それだけハードウェア・ソフトウェア共に信頼性が必要であり、また場合によっては数ミリ秒のダウンを許さない環境でフェールオーバーする必要がある為のコストであり、保険でもあります。
しかし、クラウドベンダーはこれらの機器を『仮想化』『共有化』する事で、パフォーマンスの確保とコストメリットを両立させる事になります。Amazon Web Serviceの場合、ELBのインフラの詳細については語られていませんが、APIや管理コンソールを通じてELBをコントロールする事により、従来複雑であった設定や運用をとても簡単にしてくれています。
また設計にも工夫があり、ELBを作成した際、名前(FQDN)は保証されますが、解決されるグローバルIPアドレスは保証されていません。よって、CNAMEレコードを用いてDNSにてトラフィックをコントロールする事になります。これにより、仮にプレウォーミング（暖気）やオートスケーリングによってAWS内部でロードバランサのフェールオーバー（機器間の移行処理）が走った場合でも、システム管理者は何も意図する必要はなく、透過的に処理が行われます。
＜図：ELB内部の仕組み＞
ここではELBを使って、2台のインスタンスに対し負荷分散を行います。
しかし、それぞれのウェブサーバで公開しているindex.htmlでは「I am SERVER A/C」と異なる内容にします。この状態でブラウザからELBのFQDNに対しアクセスすると、どちらか片方のページが表示され続けます。そして、表示されている方のウェブサーバを停止し、何度かリロードすると、今度はもう片方のウェブサーバのページが表示されます。これがELBの基本動作です。
もし余裕があるようであれば、インスタンスを増やす、ブラウザの枚数を増やす、ソースIPアドレスを変える等していくと面白いでしょう。
前項ではELBの基礎的な動作（正常系）を行いました。
しかし、万が一インスタンスに障害が起きたり、プロセスが停止した場合など、そのままではELBには知る術がありません。
そこでヘルスチェックという機能があり、HTTPなどで定期的に配下のインスタンスへ死活監視を行い、一定以上応答が無い場合、もしくはHTTPリクエスト200以外が返された場合に、そのインスタンスは自動で切り離される仕組みになっています。
今回はLAMP CMSとしてシェアが高いWordPressを題材に、実装を上手く使ってデータベースまでの死活監視を行います。
ここでは、WordPressのindex.phpと同じ階層に、check.phpを作成しています。
内容は以下の通りです。
<?php
require_once( dirname(__FILE__) . '/wp-load.php' );
echo('sucsess.');
exit(0);
これにより、WordPress自身の読み込みを行い、データベースや処理系といった環境が全て正常な事が確認されたうえで、200 OKがELBへ返される為、ELBはインスタンスが正常である事が確認できます。
また、wp-config.phpを改変するなどしてデータベースに接続できない状況を発生させた場合、WordPressから500 Internal Server Errorが返される為、そのインスタンスはELB配下から自動的に切り離されます。
最後に、AWSを活用し最初から拡張性と保守性を兼ね備えたスモールスタート環境例をご紹介しましょう。
1. ACM(AWS Certificate Manager)とELBの組み合わせによる、無償SSL証明書の導入
2. ELBを最初から組み込む事により後の拡張性やデプロイの容易性をアップさせる
3. Aurora等のRDSを組み合わせる事により、データベースの保守性をアップ
最初からELBを組み込む事により、以下のメリットがあります。
1. アプリケーションのデプロイを、インスタンスのスワップで行う事ができる。
2. インスタンスのスケールを無停止かつ容易に行うことが出来る。
デメリットとしては、スタートアップの頃はコストメリットが無い為、ある程度成長することが見込まれるシステムに適すること、および証明書を取得する為に事前に独自ドメインとメールの設定が必要なことです。
また、ELBはSSLのラッパーの為、例えばHTTP/2といった新しいプロトコルや新しい暗号技術を導入したい場合はこの構成では導入できません。
現在では技術が進歩し、Geo DNS(DNSによる世界的な地理分散)や、BGP Any Cast（同一のグローバルIPアドレスを最寄りのサイトへ誘導するルーティング技術）などもありますが、今回は単一サイト内におけるロードバランサを使った負荷分散についてお話しました。
ロードバランサの挙動はとてもシンプルであり、そしてとても奥深いものです。実際、オンプレミスでLVSを運用していた際、配下のサーバ1台でネットワーク設定を１行間違えただけで、ロードバランサ配下のサーバ全てがダウンしたケースも経験しており、従来とても難しいものでもありました。
しかし、Amazon Web Serviceをはじめとしたクラウドベンダー各社は、これらのハードルを大きく改善し、APIにより容易にコントロールでき、尚且つユーザのコストを大幅に抑える事に成功しており、ユーザは容易かつ気軽にロードバランサを使う事が出来るようになりました。
応用として挙げましたが、1ELB:1EC2インスタンスというスモールスタートも運用設計上とても有効です。これにより、ACMによる無償SSL証明書を使用する事ができ、尚且つ将来のスケールアウトやアプリケーションデプロイにも容易に対応可能になります。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
