『インフラデザインパターン』読んだ
2019-03-16 /
インフラデザインパターン読んだ
本当に具体的な技術に言及せずに構成方法のパターンだけに注力したような内容だった。
各パターンを列挙しては比較しているが、 選択肢の中には直交する、つまり併用できるものも多く、単純に比較することに意味があるのか疑問なところもあった。
個人的には下記について洞察が得られれば良いかな、と思って読んだ。
- 苦手分野(特にストレージ)の構成方法を知る
- パターンを実装するならどんな技術を援用するか想像してみる
以降では上記の目線で発見したことをまとめる。
全パターン検討するのは面倒くさいのでよく使いそうなパターンだけ考えてみる。
可用性
Web/AP
AP部分はRailsやSprintBootなどHTTPリクエストを消費してビジネスロジックを起動する部分。
APサーバ内で持っているセッションをクラスタ内のベースノードに"ミラーリング"するらしい。
セッション非共有分散が謎。 セッションは共有されてない=障害発生時にフェイルオーバしないのでセッションは失われる。
トランザクションのジャーナルが別のところに残っていて、それを再実行するだけで復旧できる構成なら問題ないかもしれない。 ということでWeb/APだけではちょっと優劣つけられない。
DB
N+1ではコールドスタンバイのDBサーバを持っておき、障害発生時に待機系を動的にクラスタに組み込む制御を行う調停用サーバが必要。 待機系を組み込むために調停用サーバを用意するのもなんだか効率悪いな、という感じ。
PostgreSQL
PostgreSQLの構成で下記はやったことあるかも。Streaming Replicationで可用性確保してた。https://severalnines.com/blog/top-pg-clustering-ha-solutions-postgresqlPostgreSQLだと他に使ったことないけどPostgres-XLとCitusっていうのがあるそうだ。これは後述のMySQL Clusterと似たノードを用意するみたい。
pgpool-2をクラスタのフロントエンドにおいてVIPで冗長取る。
MySQL
MySQLだと僕が知っているのはGaleraで分散させてhaproxyをフロントエンドにとっていた。MySQLだとMySQL Clusterというのがある。使ったことないけど面白そうだな。https://www.mysql.com/jp/products/cluster/features.html
仮想サーバ
アクティブなVMをN個を立ち上げておいて、クラスタリングソフトウェアで冗長化する構成。 他のアプローチとしてライブマイグレーションも紹介されているが、あれば障害発生前じゃないと意味がない気がする。 障害発生前にとったスナップショットからマイグレして再生できるから部分的には可用性を確保できていると言えなくもないが、嬉しくない。
OpenStack
https://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html
OpenStackにおけるVMライブマイグレーション
https://docs.openstack.org/nova/latest/admin/live-migration-usage.html
停止中の移動
novaはevacuate機能があるのでBlock Storageにあるディスク情報を吸い出してインスタンスを別ハイパーバイザーにリストアできる。
LAN
高信頼コアスイッチのパターンはMLAGで実現するものとみた。
あとはSTPとかを使うのかな。
WAN
両系現用 ECMPだと思うけど障害検知や片寄どうやるのか。
片系現用VRRP!
データ可用性
バックアップをどうとっておくか、っていうのが焦点になっている。
この辺はどうなんだろ、ベンダー製品固有だからあんまりノウハウ出てこない。
SAN上でレプリケーション
SAN上でコピー
セキュリティ
ネットワーク・セキュリティ
セグメント分割とファイヤウォールのはさみ方