EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

抄録:『絵で見てわかる ITインフラの仕組み 新装版』 ITインフラのキホン:まずはインフラアーキテクチャーを見てみよう【後編】

  2020/09/08 12:00

 前回は、書籍『絵で見てわかる ITインフラって何だろう 新装版』(翔泳社 山崎 泰史、三縄 慶子、畔勝 洋平、佐藤 貴彦著)の第一章から、前半部分までを抜粋して紹介しました。今回は、前回の続きとなる部分から、第一章の最後までを抜粋して紹介しています。ぜひ、最後まで読んで、ITインフラの基礎知識を確認してみてください。

1.4 水平分割型アーキテクチャ

 前節では、サーバーごとに別の役割を担い、システムを垂直に拡張する仕組みを紹介しました。しかし、より高い拡張性を実現するには、もう1つの軸への分割が必要となります。

 本節で説明する「水平分割型アーキテクチャ」では、同じ用途のサーバーを増やします。サーバー台数が増えることで、1台がシステム全体に与える影響が下がり、信頼性が向上します。また、処理を担うサーバー台数が増えることで、全体的な性能の向上も実現します。

 なお、垂直分割型と水平分割型は排他的ではなく、多くのシステムではこの2つが併用されます。

1.4.1 単純水平分割型アーキテクチャ

 図1.8のような水平分割では、東京本社と大阪支社のシステムが完全に分割されています。東京にいながら大阪支社の情報を知りたければ、大阪支社側のシステムにアクセスすればよいわけです。「Sharding(シャーディング)」や「Partitioning(パーティショニング)」と呼ばれることもあります。

図1.8 同機能を持つ複数のシステムに単純に分割する
図1.8 同機能を持つ複数のシステムに単純に分割する

 この構成では、システムが2つに分割されることにより、システム全体の処理性能も2倍に向上することが期待できます。また、2つの独立したシステムが生まれることにより、たとえば東京側のシステムに障害が発生しても、大阪側のシステムにはまったく影響しないことになり、独立性が向上します。

 しかし、東京と大阪で同じ業務アプリケーションを利用している場合、アプリケーションの更新を両方のシステムに対して都度実行する必要があります。データも東京と大阪で分断されるため、両方のデータを同時に(一元的に)利用することができません。

 また、東京と大阪の利用者数が同じくらいであればよいですが、たとえば利用者の大半が東京側のシステムを利用している場合、東京側のシステムは過負荷となり、大阪側のシステムはガラ空きとなります。これでは、システム全体の処理性能が2倍になったとは、とても言えませんよね。

 この仕組みは、地理的に遠く離れたシステムではよく利用されます。また、工場のように、各拠点が完全に独立したオペレーションを行なっている場合にも、適していると言えます。たとえば、多くのユーザーがいるソーシャルネットワーキングなどのWebサービスでは、ユーザーIDによるサーバー分割(Sharding)を実施することがよくあります。

■メリット
  • 水平にサーバーを増やせるので、拡張性が向上する
  • 分割したシステム同士は独立しており、相互に影響しない
■デメリット
  • データを一元的に見ることができない
  • アプリケーションの更新は両方に対して行なう必要がある
  • 処理量が均等に分割されていない場合、サーバーごとの処理量にかたよりが出る

1.4.2 シェアード型アーキテクチャ

 通常の企業システムであれば、よほど仲が悪い組織でない限り、東京と大阪で別々の業務アプリケーションを利用することは少ないでしょう。シェアード型では、単純分割とは異なり、一部レイヤーに限って相互接続を行ないます(図1.9)。

図1.9 データ層を相互接続する
図1.9 データ層を相互接続する

 この構成では、東京側のシステムにおいても、必要な場合は大阪側のデータにアクセスすることが可能となります。逆もしかりです。データ層はデータの保管庫であり、機密情報を扱うことも多くなります。データが各地に点在しているよりも集中的に管理するほうが、セキュリティ面や保守面において有利な場合があります。

 また、この構成ではデータをまとめて参照できるので、たとえば本社の商品管理部が全拠点の商品情報を参照できるといったメリットもあります。

■メリット
  • 水平にサーバーを増やせるので、拡張性が向上する
  • 分割したシステムそれぞれで、どちらのデータでも利用できる
■デメリット
  • 分割したシステム同士の独立性が低くなる
  • シェアした階層においては、拡張性が低くなる
Column

集中→分散→集中→分散

 気づけば筆者もミドルエイジにさしかかり、そろそろ人生の半分ぐらいITに関わってきたことになります。これまでに、脱ホスト/オープン化(分散)→仮想化/クラウド化(集中)→エッジコンピューティング(分散) イマココ!、というアーキテクチャの変遷を見てきました。

  エッジコンピューティング(Edge Computing)は、最近のキーワードです。これは、仮想化によるデータセンター統合や、クラウドへのシフトにより、ネットワーク帯域と費用の増加が足かせになりつつあるという背景から、地理的に近い場所に処理を分散し、処理結果のみ中央に送ろうというアーキテクチャを指します(図1.A)。あれ?クラサバ時代を思い出しますね。

  集中、分散といった概念は繰り返しますが、利用されるテクノロジーはより安価に、より使いやすくなっているので、毎回新しい発見があるのも、楽しいものです。

  集約のメリットは構成のシンプルさ、つまり管理性がよいことで、分散はその裏返しです。このため、エッジコンピューティングでは、いかに管理の手間を増やさず、サーバーを分散するかがポイントになります。

  • 分散配置されるネットワーク機器を集中管理したい(ルーティング設定の配布や状態監視)=SD-WANのこと
  • デバイスや処理装置も集中管理したい(処理の制御や状態監視)=IoTの一要素

 エッジコンピューティング、SD-WAN、IoTというキーワードを聞くと、「もうおなかいっぱい」と思う方もいるかもしれませんが、アーキテクチャ変遷の動機はこのようにいたってシンプルです。

図1.A エッジコンピューティング
図1.A エッジコンピューティング

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


関連リンク

著者プロフィール

  • EnterpriseZine編集部(エンタープライズジン ヘンシュウブ)

    「EnterpriseZine」(エンタープライズジン)は、翔泳社が運営する企業のIT活用とビジネス成長を支援するITリーダー向け専門メディアです。データテクノロジー/情報セキュリティの最新動向を中心に、企業ITに関する多様な情報をお届けしています。

バックナンバー

連載:翔泳社の本
All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5