これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
負荷分散装置（ロードバランサ、Load Balancer）の話をしたいと思います。
ロードバランサは、その名のとおり「負荷を分散させる」ための装置（専用ハードウェア、仮想アプライアンスまたはソフトウェアやサービスもあります）です。
クライアントからの要求（リクエスト）を分散させることで、負荷を軽減することが主目的です。
では、誰の何の負荷を軽減するのかというと、サーバーに対するネットワーク経由のリクエストを振り分けることで負荷を軽減することが可能になります（振り分け情報がネットワーク・レイヤーによって異なることから、OSI参照モデルでのトランスポート層を解析する「L4スイッチ」とアプリケーション層まで解析する「L7スイッチ」の2種類に大別されます）。
例えば、あなたがWebサーバーでサイトを運用していると仮定しましょう。
運営しているうちに人気サイトになったことでコンシューマ（クライアント）からの膨大なリクエストを1台のサーバーで捌き切れなくなった時に、ロードバランサを適用することで問題を解決できるのです。
図示した仕組みは以下の様になります。
今までWebサーバーが直接受けていたコンシューマからのリクエストは、ロードバランサが替わりに受け取るようにサーバーの前面に配置します。
ロードバランサが受け付けたリクエストは背面に配置されているWebサーバーに伝言するのです。この時に背面のWebサーバーを複数台配置させること（サーバーファーム「農場」）ができます。ロードバランサがサーバーファームにリクエストを振り分けてくれる機能を持っているのです。
サーバーファームに2台のサーバーを設置することで、二頭引き馬車になり二馬力となります。これまで1台のサーバーに集中していた処理を2台に振り分けることで、単体に掛かる負荷を半分に軽減できるようになるのです。
さらに、農場に置く馬（サーバー）を4台にすると1/4、8台にすると1/8、と台数を増やすことで、馬一頭（サーバー単体）あたりの負荷が軽くなる仕掛けです。
この場合に、どのように振り分けするかの作戦（負荷分散アルゴリズム）が大事になりますが、基本的には均等に負荷を分散させることが好ましいのです。
これが順番に振り分ける「ラウンドロビン(Round-Robin)」であり、代表的なアルゴリズムになります。
この他のアルゴリズムとしては、（特にWebの場合であれば）クライアントとのコネクション数が最も少ないサーバーは余裕がある（負荷が少ない）と見なすことができますので、そこに振り分ける「リースト・コネクション（Least Connections）」があります。
また、同様に応答が速いサーバーは処理が速いと見なしてそこに振り分ける「ファーステスト・レスポンス・タイム（Fastest Response Time）」という作戦などもあります。
さらには、これらアルゴリズムに「重み付け(Weighted)」を加味する方策も加わることになります。
このように、アルゴリズムを気にしなければならない理由には、背後にあるサーバーの性能が関係します。サーバーファームにあるサーバーが同じ性能であれば順当に振り分ければ良いのですが、寄せ集めで性能にばらつきがあれば、処理をこなせるサーバーにより多く振り分けることで効率が良くなるからです。
また、リクエスト毎の処理内容が大きく異なる場合も考慮の対象となるでしょう。
結果として各々のリクエストに対して、スムーズに応答可能になるように構成する必要があるからです。
そして、ロードバランサを構成に組み入れることで、別の恩恵も受けることになります。それは、Webサーバーに障害が起きた場合です。
Webサーバー1台で運用していてサーバーがダウンした場合、事前に代替えを用意していなければ復旧は大変です。稼働再開するまでには時間を要することになり、その間のリクエストに応答することが適いません。
これに対してロードバランサの背後にサーバーファームが構成されていれば、もし1台のサーバーがダウンしたとしても、別のサーバーが処理し応答し続けることが可能となります。これが冗長化による恩恵です。
クライアント側からみれば何事もなく継続しているように思えることでしょう。
ただし、サーバーファームを構成しサーバーの台数を2倍に増やせば、故障する確率は2倍、台数を4倍にすれば故障する確率も4倍となります。台数に比例して故障する確率も同時に増えることを忘れてはいけません。ですから、各々のサーバーの健康状態を逐次チェックして、正常に応答しないサーバーを故障（ダウン）したと判断して処理を振り分けないようにしなければなりません。
この冗長構成を可能にする機能が「死活監視（ヘルスチェック、Health Check）」であり、実現のために必要とされます。
ヘルスチェックではサーバーが正しく応答するか否かで健康状態を判断しますが、このチェックを何の項目で行うのかも重要になります。
これには幾つかのレベルでのチェック方法があります。IPレベル（ping）、TCPレベル（SYN/ACK）、HTTPレベル（GET/POST）、アプリケーション・レベル（成功メッセージなど）、などの方法で健康状態を管理することが行われます。
pingが通ったとしても、Webサーバーが立ち上がっていないということもありますので、サーバーが行う処理内容によっては、適切なチェック方法の選択がロードバランサにとって必要となるでしょう。
大まかにロードバランサが必要とする主機能について述べてきましたが、実際に適用しようとする際には、他にも検討する項目や様々な機能的な要望があると思われます。
機能ではセッション維持（Sticky Session）、SSLオフロード（SSL Offload）などに加えて、本来の機能ではないですがコンテンツ・キャッシュや圧縮機能、ファイアウォールまでも有する多機能なものも登場しています。
用途に合わせてロードバランサの選択が必要です。
そして何より考慮すべき点は、ロードバランサの故障です。
ロードバランサを採用した構成によりすべてのクライアントの玄関（入口）となりますので、ロードバランサがダウンしてしまうと誰もサーバーを利用できなくなってしまいます。
いわゆる、「単一障害点（Single Point of Failure, SPOF）」となるのです。
ですから予備のロードバランサをスタンバイさせる構成（L2スイッチなど用いてさらに複雑な構成になってしまう場合もありますが）、または、完全な冗長化も視野に入れることも検討すべきかもしれません。
このスタンバイ構成や冗長化には、仮想ルーター冗長プロトコルである「VRRP(Virtual Router Redundancy Protocol)」がロードバランサにも採用されていることが散見されます。
VRRPはパケットをマルチキャスト・アドレスに送出し、ロードバランサをヘルスチェックできるのです。また故障を発見した際の復旧手順（フェイルオーバー、Failover）が用意されているものもあります。
構成と配置を考察する場合には、まずは各機器がどのような主たる役割を果たせば良いのかと骨子を練り、その後に細かい要求を満たせるように具現化していく手順があるでしょう。全体を構築するには個々の役割とそれらの関係性を良く見る必要がありあそうです。
ところで「ゼアネス・ザットネス（Thereness-Thatness）」という言葉は心理学用語（造語）だそうで、装置（Apparatus）の名前のようです（装置はテーブル形状の様子 Thereness-Thatness Table）。
研究の詳細は存じ上げませんが、この実験は「知覚」に関するもので、その一つは、被験者に写真を見せる際に、第三者が該当の写真との距離設定を変更することで変動があるのかを調べるもので、感情的関与がなくても設定の変動性の面で「見え方（認知）」に差異が現れることが確認されました。
感情の刺激が知覚に差分の変動性を齎す（もたらす）のと同様に、対象物（オブジェクト）の配置によって変動性が顕在化するのであり、ニュートラルな刺激とは、対照的に正負の両方が認知に関連するとの事なのです。
筆者は心理学について完全に門外漢ですが、感情によって見え方が違うのは理解ができます。皆さんも少なからず何かしらの経験があることでしょう。
しかしながら、自分と見ているもの（写真）との位置関係（配置や距離）によって見え方にも差異が出るというのは些少ながら驚きがありました。
ですが、感情も相手との位置関係（物理的だけではなく心の距離も含まれますが）によって変化するのですから、見え方にも関係あるのは不思議ではないのかもしれません。
この言葉を知るきっかけになったのは、坂本龍一の曲でこの造語をタイトルにした「ザットネス・アンド・ゼアネス（Thatness and Thereness）」があったからです。
この曲は坂本龍一のセカンド・アルバム「B-2ユニット（B-2 UNIT）」に収録されています。彼の初期では珍しく彼自身がボーカルを取っている曲で、独特の雰囲気があります。朴訥（ぼくとつ）とした歌い方が心地よい反面、シリアスさ、狂気すらも感じさせるものでして、耽美的でもあり虚無的でもあります。
牧歌的なメロディの一部が耳にこびり付いて、おもわずそのフレーズを口ずさんでしまうのも不思議なものです。
曲名の"Thatness and Thereness"は歌詞のサビとしても登場しますが、あたかも傍観者の視点で「そこにも、ここにも（Thatness, Thereness）」と囁いています。
この呟きは聴き手である我々に問い掛けられているのかもしれません。
「それが何に見えるのか、それがどこに見えるのか（Thatness, Thereness）」
次回もお楽しみに。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
