class: title, smokescreen, shelf, no-footer # 高信頼化システム <div class=footnote> <small> <small> (脚注) 今回は、ネットワーク接続したサーバ群による信頼性向上の解説なので、TCP/IPの理解が大前提です </small> </small> </div> --- class: compact # おしながき <div class=footnote> <small> <small> 【大事な話】 クラウドは<B>銀の弾丸</B>(F.J.Brooks「人月の神話」)ではありません。 (a)物理作業の必要がなく (b)(<B>「必要なサーバ・ITサービスを、必要な時に、必要な量だけ」)</B> レンタルできるサービスです。 この観点で、トヨタ自動車の<B>ジャストインタイム(JIT)</B>生産方式のIT版です (注:生産ではないので在庫の考え方が異なりますけどね)。 クラウド演習で (おそらくAWSにあるメニューの意味が分からない) <B>最初の関門は、ネットワークと冗長構成</B>(今回のテーマ)です。 クリック2,3発で簡単に買える作りこまれたAWSサービスも多数ありますが、 動作原理が分からないままでは、 うまく動かないときに、あなたはどこが悪いか判断できない</B>でしょう。 ちなみにOSの知識が必要になるのは、もう少し先のステージです </small> </small> </div> 1. ハードウエアによる高信頼化システム ... ここは、まだハードウエア単体での話 1. 冗長構成 ... ここから後は**分散システムになり、ネットワーク、クラウドの裏側**の話 1. 負荷分散とロードバランサの技術 1. クラスタ 1. 分散システムのケーススタディ (クラウド演習むけの解説) 1. ~~Googleの分散システム(こんなとこまで話す時間はないので省略)~~ --- class: title, smokescreen, shelf, no-footer # ハードウエアによる高信頼化 <div class=footnote> <small> <small> 特別なハードウエアによる2系統化で高信頼性を追求する手法です。 <B>情報処理試験にあわせて現用/待機系という用語を使います</B>が、 それらは汎用機業界の用語?個人的には現場で聞いたこと無い気が (よくみるのはA系/B系?)... </small> </small> </div> --- class: img-right,compact # デュプレックスシステム, デュアルシステム <div class=footnote> <small> <small> </small> </small> </div>   - **デュプレックスシステム(duplex system)** <br> 現用系と待機系の二系列の構成: 障害時には待機系が現用系を引き継ぎます - **デュアルシステム(dual system)** <br> 同時に同じ処理を行い相互に結果を照合しています。 障害発生時は障害を起こした系を切り離して処理を続行します - 製品としては、パソコンではなく汎用機や高価なワークステーションクラス <br> <small> <small> 単にパソコンを2つつなげてもダメで、 特別に作りこまれたハードウエアが必要です。 たとえば照合にはCPU間の高速通信回路が必要なはずだし、 OSもシステム間で同期を取る特別な仕組みが必要です。 普通のTSSでは実行順もタイミングも予測不能なので、そのままでは使えません </small> </small> --- class: img-right,compact # デュプレックスシステムの待機系について補足 <div class=footnote> <small> <small> </small> </small> </div>  <small> - 「非常時に備えて仕事をせずに待つ」待機系は作りやすいですが、 設備投資の無駄なので - ふだん待機系は別の仕事(例:バッチ処理)をしていて、 現用系に障害がおこると現用系の仕事を引き継ぐ動作をします (おそらく銀行などで、そういう使い方をしていると思いますが、 実物を運用したことが無いので自信なし) </small> --- class: title, smokescreen, shelf, no-footer # 冗長構成 <div class=footnote> <small> <small> (脚注) 普通のハードウエアを複数運用して信頼性を向上させます。現代では主流派 </small> </small> </div> --- class: img-right,compact # SPOF (Single Point of Failure)をなくすためには冗長構成 <div class=footnote> <small> <small> (脚注) 大災害を想定するなら東京や関東地方の規模でもSPOFです。 きちんとしたサービスでは、 数百キロ離れた別のデータセンターで別系統のサービスを待機させる設計をします (AWS用語ではマルチ<B>リージョン</B>構成。マルチ<B>AZ</B>構成は大規模災害対策として不十分) </small> </small> </div>  - この一ヶ所が落ちるとシステム全てに影響がある場所を単一障害点、 略して**SPOF(Single Point of Failure)**と呼びます - 右図(詳細は後述)では、たとえばスイッチは一つしかないのでSPOFです - 機材も配線も複数用意して一つのシステムとして動かすことが**冗長化**です (デュプレックスやデュアルシステムも冗長構成の一種ですが、 クラウド時代では、 一台の特殊なPCの中身の話より、 普通のPCの群れからなる冗長構成がテーマ) --- name: redundancy-figure-is-too-hard-to-draw class: img-right,compact # 冗長構成のイーサネット配線を本気で書くと大変で...   - 冗長構成のイーサネット配線を本気で書くと図(上)のような配線になります。 二系統しか書いていませんが、もう大変なことになっています - そういうわけで、**このあとは配線を極力省略**して、 図(下)のように**論理的なつながりを説明する最低限の線だけを書く**ことにします (インターネットと書いてあれば、 本来は境界線にルータやファイアウォールもあるのですが、 それらも適宜省略していきます。 **あうんの呼吸**で補って読み取ってください) --- class: img-right,compact # アクティブ-アクティブ、アクティブ-スタンバイ <div class=footnote> <small> (脚注) 構成によってライセンス費用が変わるので、運用上、これらの区別は重要です </small> </div class=footnote>   - ネットワーク機器や分散システムでも複数台構成を運用します。 障害にそなえて、**監視**=互いの**生死確認**(やモノによっては**状態の共有**)をしますが、 結果の照合などの複雑な処理は普通していません - **アクティブ-スタンバイ**(duplex似) <br> 電源が入っている待機が**ホットスタンバイ**、 電源が入っていない待機は**コールドスタンバイ**(切替は手動で電源ON) - **アクティブ-アクティブ**(dual似でも異) <br> N台の機器がすべて動作している状態 <br> (N台あれば性能がN倍の場面も多々) --- class: title, smokescreen, shelf, no-footer # 負荷分散とロードバランサの技術 <div class=footnote> <small> <small> 多数のサーバがある場合、均等に負荷がかかるとよいですよね? あと障害時はどうするべきでしょうかね? </small> </small> </div> --- class: img-right,compact # DNSを利用したロードバランサ(正常時) <div class=footnote> <small> <small> (脚注) 多数のユーザからのアクセスがあるなら、 サーバ群の忙しさが統計的に同じくらいという意味です。 「(ある数分に)ユーザAがサーバを順にアクセスする」わけではありません。 しかしながら 「ユーザZが毎日サイトを訪問するとして、 1年で平均をとれば、全サーバに同じくらいの頻度でアクセス(平準化)している」でしょう (ほとんど統計力学のエルゴード性の話をしているようだ:-) </small> </small> </div>  <small> - DNSの問い合わせに対し、 DNSサーバはサーバ1,2,3のIPアドレスを順番に返していきます: ユーザAの問い合わせに対しては「サーバ1」、 ユーザBには「サーバ2」と返すことで、 **サーバアクセスが平準化(ロードがバランス)**されていきます - サーバA:サーバBに割合2:1といった設定も可能 - 簡単でうまく動く方法ですが、 問題は障害時 ``` 設定例 [/etc/namedb/example.com.zone] ; コメント www IN A 10.0.0.1 ; サーバ1は多め,2/4の割合 www IN A 10.0.0.1 www IN A 10.0.0.2 www IN A 10.0.0.3 ``` </small> --- class: img-right,compact # DNSを利用したロードバランサ(障害時) <div class=footnote> <small> <small> (脚注) アクセスの途中でサーバ障害になったユーザは DNS query cacheが切れるまでハズレにアクセスし続けることになります。 クラウド側からは制御できないので素直にロードバランサを使うべきでしょうね。 DNSロードバランスで十分か?はコストの兼ね合い </small> </small> </div>  <small> - 根底の問題はクライアント側のDNSキャッシュ - サーバ障害時は、 壊れたサーバのIPアドレスを設定から削除し、 **DNSサーバは生きているサーバ群のIPアドレスだけを答える**ようにします <br> => **障害発生以降にアクセスしてくるユーザは死んだサーバにアクセスしません** - 故障したサーバをDNSの設定からはずすには次の仕組みを作り込む必要があります <br> (a)サーバの生死監視 (b)DNS設定の更新 - **AWS**の**route 53**というDNSサービスには、これらの機能が初めからあって便利です (route53ベースの冗長構成を運用してもいい気になれます) </small> --- class: img-right,compact # ロードバランサ(専用装置)  - 一般にはロードバランサという専用装置(ハードウエア)をサービスの前面に置き、 その装置がサーバへの振り分けや生死監視、 障害時のfail over (サーバを振り分け先から削除、 障害サーバ行きのセッションを別のサーバへ引き継ぐなどの処理)を行います - 製品例 - F5 Networks社(1996-, 米)のBIG-IPが有名 (最近のは知らないけど昔のBIG-IPの中身は単なるBSD Unixのサーバ) - RadwareのLinkProof(1997-, Israel) --- class: img-right,compact # ロードバランサ(特にHTTP/HTTPSのリバースプロキシ)  <small> - 前面に立つサーバが**一度通信を受けた後に裏側のサーバへ中継**します。 <small> 通常、プロキシは社内/学内->インターネット向きで利用するものなのですが、 この構成は**逆向き**なので**リバース**と呼ばれます。 proxyに生死監視やfailoverを付け加えれば前頁と同じ動作になります。 多くのサービスがWebベースなので、 リバースプロキシといえば、 たいていHTTP/HTTPSの振り分けの話です </small> - 製品例: とうぜん専用ハードウエアでも出来ますが、 **nginx**(2004-,露,エンジンエックスと発音します;OSS版と商用版あり)が有名です。 <small> nginxはオープンソースですが、 (機能が拡張された)商用版もあり、nginx社から商用サポートも受けられます。 2019年、F5 Networks社がnginx社を買収したので今はF5傘下です。 つまりロードバランサの分野ではF5が圧倒的と言えます </small> </small> --- name: nginx-apache-sql-3layers class: img-right,compact # ロードバランサ(nginx) + apache + SQLの三層構成 <div class=footnote> <small> <small> (脚注) HTTPS(443/tcp)利用時のHTTPS終端はnginxになります。 nginxから裏側のサーバむけ通信はHTTP(80/tcp)です。 AWS用語でいえばVPC内ではHTTPを使うということです。 通信におけるオーバヘッドの減少という側面もありますが、 HTTPSの公開鍵の認証やfailoverを考えると、この構成の方が楽ですよね。 もちろん(nginxより裏側のセグメントつまり)VPC内部はアタックされない前提です </small> </small> </div>  <small> - 前面にnginx, その背後に中間層としてapache、 apacheの裏側=最奥にSQLサーバを配置する構成もよく見られます <small> (apacheのほうが拡張機能が豊富なので、こういうWWWサーバの使い分けをしますが、 普通の使い方なら、二層目もnginxで運用できるでしょう) </small> - AWSには、 **ELB**(Elastic Load Blancer)というロードバランサ、 **RDS**(Relational Database ...)というSQLサービスがあります。 RDSではSQLソフトウエアを選べますが、 [**Aurora**](#aws-aurora)を選べば初めから**クラスタ**構成 (もちろん、そのぶん高価)です </small> --- class: title, smokescreen, shelf, no-footer # クラスタ構成 <div class=footnote> <small> <small> (脚注) クラスタの用語は応用情報レベルみたいですが、 最終課題のために説明しておきます </small> </small> </div> --- class: img-right,compact # クラスタ <div class=footnote> <small> <small> </small> </small> </div>  - 多くの機器を連結・連携し、 それらが一つの機器であるかのように振る舞うシステムを**クラスタ(cluster)**と呼びます - 図では単にSQLサーバと書いてありますが、 実サービスでは、 一台のSQLサーバの障害で全サービスが止まらないように、 SQLサーバ群が一つのSQLサーバであるかのように動かします - このようにクラスタは一般に何らかの**協調動作**をしています。 特に**確実に書き込んで保存する**のは難しい処理で、 そこをどうサーバ群が連携して処理するのか?がクラスタ内部動作の最大の関心事 --- class: img-right,compact # クラスタ用語の分類   - **高可用性(HA = High Availability)**、高信頼化、高性能化のためにクラスタ化 - クラスタの分類 - **フェイルオーバー**(fail over)型 <br> (**アクティブ-スタンバイ**) - **負荷分散**(load balance)型 <br> (**アクティブ-アクティブ**) --- class: title, smokescreen, shelf, no-footer # 分散システムのケーススタディ<br><small><small>〜クラウドサービスの裏側で使うレベル〜</small></small> <div class=footnote> <small> <small> 中間試験には出しませんが、 演習(発展)でカスりそうなケーススタディを少し </small> </small> </div> --- name: cluster-postgresql class: img-right,compact # SQLクラスタの例(PostgreSQL)  <small> - 前面にpgpool-II (2006-, originalのpgpoolの作者はSRAの石井さんで2003)を作ります - アプリからクエリを投げる先のSQLサーバはpgpool-IIクラスタに付ける仮想IPアドレス (192.168.0.254)になります - pgpool-IIクラスタがロードバランサー相当の機能です。 pgpool-IIサーバ同士は互いに監視していて、 障害時にはfailoverしてくれます - pgpool-IIから裏側のPostgreSQLのマスタ(図ではサーバ1)に更新を書き込むと、 裏側でサーバ2と3へ同期します(バックアップを取ります) - ちなみに参照クエリは、サーバ1,2,3どれに尋ねても同じ答えが返るので、 pgpool-IIで負荷分散すると3倍速になるというわけです </small> --- name: aws-aurora class: img-right,compact # AWS RDS Aurora <div class=footnote> <small> <small> (脚注1) AWSの<B>AZ</B>(Availability Zone)は、 同一地方に存在する電源やネットワークが別のデータセンター設備です。 大災害ではAZ群が同時障害になる(全滅する)可能性があります (脚注2) いわゆる札束ビンタ=金で解決ですよ！ </small> </small> </div>  <small> - AWS RDSでは複数のRDBMSソフトウエアが選択できますが、 Amazon製のAuroraはデフォルトで十分考えられています。 特別な理由が無いならAuroraの利用を考えるべきでしょう <br> (ただし予算があれば;-) - はじめから**マルチAZ**対応で、**6重に書き込み**をします (**3つのAZで2重に書き込み**) - デメリット - SQL互換インターフェイスは、 MySQLとPostgreSQLのみかつ対応バージョンも少し古めらしいです。 ここが合わない場合、既存SQLサーバからのAurora移行が困難です </small> --- name: etcd class: img-right,compact # 分散データベースの例(etcd) <div class=footnote> <small> <small> (脚注1) etcdは<B>kubernetes</B>で設定を保存する中核部分で使われています (脚注2) 選挙は<B> <A HREF="https://www.usenix.org/system/files/conference/atc14/atc14-paper-ongaro.pdf"> Raftコンセンサスアルゴリズム </A> </B> (Googleは<B>Paxos</B> Algorithm) (脚注3) Paxosの初出は Lamport, L., "The part-time parliament", Technical report 49, Digital Equipment Corporation Systems Research Center (1989). (脚注4) 第2世代Googleには2種類の分散ファイルシステムがあり、 小さいデータ用の分散ファイルシステム(or キーバリューストア)がchubbyです。 chubbyを参考に作られたNoSQLソフトウエアがCoreOS社のetcdやApache zookeeper </small> </small> </div>  <small> - NoSQLという種類のソフトウエア - 動作は、[PostgreSQLクラスタ](#cluster-postgresql)と似ています。 leaderノードが更新を受け取り、他のfollowerノードに更新を伝えます - 障害でleader不在になった場合、 followerの中からleaderを選挙で選び処理を続けます。 なお、 ネットワーク障害に対応するため**ノード総数は奇数**である必要があります (詳細は省略) ``` KEY => VALUE ``` </small> --- name: tidb class: img-right,compact # 分散データベースの例(TiDB,いわゆるNewSQL) <div class=footnote> <small> <small> (脚注1) RDBMS(SQL)がスケールしないのでGoogle論文以降NoSQLが流行しました。 ただNoSQLは使い勝手が独特だし、 SQLが使いたいということで一周まわって分散データベースNewSQLが今の流行 (脚注2) さすがに、これはクラウド演習で誰も使わないか? (脚注3) ちなみに、さくらインターネットならTiDBサービスあり (脚注4) 大手ではPayPayが裏側でTiDBを利用 </small> </small> </div>  <small> - 前面にMySQL互換インターフェイスを提供するサーバ群がおり、 裏側のストレージエンジンがデータを保存します。 ストレージエンジンTiKV部分は、 RocksDBベースの分散キーバリューストアです。 TiKVは、 ある程度の大きさごとのRaftグループから構成されます - ちなみに普通のRDBMSの構造も(クラスタとかになってはいませんが) 管理部分とストレージエンジンの二段がまえです (設定ファイルで利用するストレージエンジンを選択可能です) </small>