マルチAZは冗長性の夢を見るか? / Do Multi-AZ Dream of Redundancy?

by cidr

Slide 1

Slide 1 text

マルチAZは冗長性の夢を見るか? 西田龍斗 (@cidr_cuckooo) JAWS FESTA 2019 SAPPORO

Slide 2

Slide 2 text

自己紹介　・西田龍斗(にしだりゅうと)  - Twitter @cidr_cuckooo    ・経歴  - 2019年1月に個人事業主として開業  - 2019年3月に釧路高専3年次退学  以後フリーランスプログラマとしてアプリケーション開発に携わる。   

Slide 3

Slide 3 text

マルチAZは冗長性の夢を見るか? 　  マルチAZ構成  組んでますか? 

Slide 4

Slide 4 text

マルチAZは冗長性の夢を見るか? 　参照 : 東京リージョン(AP-NORTHEAST-1)で発生した..

Slide 5

Slide 5 text

マルチAZは冗長性の夢を見るか? 　東京リージョン内単一のAZであるapne-az4というIDのAZで発生。    複数のAZを併用する「マルチAZ構成」を組んでいれば影響を避ける事が出来た障害であったため、SNSやネットメディアではマルチAZを推奨する意見が多く見られた。    参照 : 東京リージョン(AP-NORTHEAST-1)で発生した..

Slide 6

Slide 6 text

マルチAZは冗長性の夢を見るか? 　  マルチAZは有効だった！      どんどんマルチAZ構成を使っていこう！ 

Slide 7

Slide 7 text

スライドショーの最後です。クリックすると終了します。 

Slide 8

Slide 8 text

マルチAZは冗長性の夢を見るか? 　  本当に？？ 

Slide 9

Slide 9 text

マルチAZは冗長性の夢を見るか? 　  マルチAZ構成は有効ではあるが・・・    よく考えると    ・運が悪く複数のAZで同時に障害が起きるかもしれない     ・大規模災害時には複数AZやリージョン単位で被害を被るかもしれない     ・AWSがハッキングされて利用出来なくなるかもしれない     ・某国から飛んできたミサイルがどこかのデータセンタに落ちるかもしれない     ・そもそもマルチAZでも防げなかった状況も  

Slide 10

Slide 10 text

マルチAZは冗長性の夢を見るか? 　  Q : ここまで考えるのは過剰じゃないか？    A : 障害対策・災害対策は楽観的に考えない！      BGPが間違った経路情報を流したり、全DNSがダウンしたりでインターネットが崩壊した時とかは流石に諦める・・・ 

Slide 11

Slide 11 text

マルチAZは冗長性の夢を見るか? 　  そもそもマルチAZ構成は  大前提です。 

Slide 12

Slide 12 text

マルチAZは冗長性の夢を見るか? 　  提供しているアプリケーションに対して、ある程度は自身で可用性を担保できる仕組みを作るべき。  ・でもマルチリージョンとかハイブリットクラウドは費用が沢山かかる     ・コールドスタンバイを組んだ所で、通常時は動かないなら無駄に思えるし、予備も落ちたら意味がない    ・そもそもどうすれば良いのか分からない  

Slide 13

Slide 13 text

マルチAZは冗長性の夢を見るか? 　  サービスが停止したら、  すぐに別の場所で運用開始  できるような設計を組む。 

Slide 14

Slide 14 text

マルチAZは冗長性の夢を見るか? 　  そうだ。  コンテナ使おう。 

Slide 15

Slide 15 text

マルチAZは冗長性の夢を見るか? 　  コンテナはいいぞ  ・1つのアプリケーションを1個のコンテナに閉じ込めていろんな所で再利用できる。移植が簡単     ・ミドルウェアや依存ライブラリを閉じ込めることが出来るのでホストの環境が汚れない     ・環境をコードで管理するので、バージョン管理が可能になり、ヒューマンエラーも減る     ・何台マシンがあろうとコード一つで簡単に展開できる     ・コンテナやコンテナオーケストレーション、その他周辺サービス群が成熟している  

Slide 16

Slide 16 text

マルチAZは冗長性の夢を見るか? 　  Why Containers? 

Slide 17

Slide 17 text

マルチAZは冗長性の夢を見るか? 　  一般的なマルチAZ構成で得られる可用性(Availability) 

Slide 18

Slide 18 text

マルチAZは冗長性の夢を見るか? 　  コンテナ技術による可搬性(Portability) 

Slide 19

Slide 19 text

マルチAZは冗長性の夢を見るか? 　  可搬性で可用性を補う  インフラ・AZ・リージョン障害があっても、別の正常なマシンですぐにサービスを提供できる。  

Slide 20

Slide 20 text

マルチAZは冗長性の夢を見るか? 　  可搬性で可用性を補う  アプリケーション障害(バグ・脆弱性)があった場合、そのバージョンのアプリをローカルで検証できる。  

Slide 21

Slide 21 text

マルチAZは冗長性の夢を見るか? 　  可搬性で可用性を補う  スケーリングが容易になる。(AutoScalingとの親和性が高い)    

Slide 22

Slide 22 text

マルチAZは冗長性の夢を見るか? 　  コンテナ  オーケストレーション 

Slide 23

Slide 23 text

マルチAZは冗長性の夢を見るか? 　  Kubernetesを使う  発音は「クーべネティス」?「クーバネティス」?   省略してK8s「ケーエイツ」と呼ぶことも。     K8sのゴールは可搬性・拡張性・自己修復を提供し、サービス運用負担を減らすためエコシステムを整備していくこととなっているので、今回強調したい「可搬性によって可用性を担保する」についても適している。  KubernetesはGoogleがかつて「Borg」として、社内向けに開発したコンテナオーケストレーションツール。    デプロイからコンテナ運用の自動化、セルフヒーリングといったコンテナ開発を支える複数の機能を持つ。  

Slide 24

Slide 24 text

マルチAZは冗長性の夢を見るか? 　  Docker-Swarmを使う  Swarmじゃ出来ない事の例として、依存関係にそってコンテナの立ち上げが出来ないが、 Docker-Swarm + Docker-Composeで解決できるように、Dockerのエコシステムフル活用で Kubernetesと遜色なく利用することが出来る。     ちなみにDocker-Composeもコンテナオーケストレーションツールとして分類される。   Docker-SwarmはDocker公式で提供されているコンテナオーケストレーションツール。    Kubernetesと比較し、出来る事は少ないものの学習コストはその分低く、 Swarmが持つ機能だけでも十分な事もある。  

Slide 25

Slide 25 text

マルチAZは冗長性の夢を見るか? 　  しかし・・・  Docker-SwarmはKubernetesよりシンプル。   だが、利用者が少なくドキュメントもK8sほど整っているわけではない。   マネージドサービスに至っては皆無なので捉えようによってはK8sより学習コストが高くなることも。   Kubernetesは複雑で学習コストが高い。   クラウドのK8sマネージドサービスは利便性も高く、各クラウドプロバイダでサービスネイティブに扱えるが、そのクラウドプロバイダ内でしか利用できない。   GCPのAnthosはハイブリッドクラウドに対応はしているものの、AnthosでAWSを利用しようとすると EKSほどAWSネイティブには活用できない。  

Slide 26

Slide 26 text

マルチAZは冗長性の夢を見るか? 　  重要なのはクラウドプロバイダそのものを意識せず扱える構成  クラウドプロバイダやオンプレミスといった事を開発側が意識せずに扱える構成を組む事で     「可搬性による可用性の担保」を出来る環境が整う。  

Slide 27

Slide 27 text

マルチAZは冗長性の夢を見るか? 　  マネージドサービスを使わない選択肢  クラウドプロバイダを意識しない、クラウドプロバイダに依存しないとなると、マネージドサービスを用いないという選択肢が生まれる。     マネージドサービスを使うことは、コスト負担減や利便性の向上など、沢山のメリットがある反面、クラウドプロバイダへの依存度が上がる。     これは運用スタイルをプロバイダに合わせる必要があったり、障害時の復旧やダウンタイムなどがコントロール出来なくなる。    その他にも、各プロバイダ得意とする分野があるのに対し、多くをマネージドで構成するとプロバイダ間の連携を取る事も難しくなる。  

Slide 28

Slide 28 text

マルチAZは冗長性の夢を見るか? 　  Rancher等のようなKubernetes as a Service(KaaS)を使う  Rancherを使うと、Kubernetesクラスタとして EKSやGKEといった各クラウドプロバイダの提供する Kubernetesマネージドツールを選択できる。   Kubernetesが目指す目標の中に可搬性がある。   これはまさに、裏で動くマシンがプロバイダのものか、オンプレなのか関係なくどこでも動かせる事が目的になっている。  しかし実際にそれをやろうとすると学習コストがかかる。   それを補うため生まれた概念がKubernetes as a Service。   題にあるが、RancherはKaaSの一つで、コンテナオーケストレーションツールでもある。  

Slide 29

Slide 29 text

マルチAZは冗長性の夢を見るか? 　  課題 

Slide 30

Slide 30 text

マルチAZは冗長性の夢を見るか? 　  データの保存  コンテナを扱う場合、データの永続化やバックアップ、ストレージ・DBと、注意を払わなければいけない所が生まれてくる。    アプリケーションの可用性(可搬性)は担保できても、データそのものの可用性(可搬性)を担保するのは難しい。    CAP定理と呼ばれ、「一貫性・可用性・ネットワーク分断耐性」の3つの特性の内、DBは2つまでしか持てないのかという長年の研究テーマにもなっている。     プログラマやシステムエンジニアと呼ばれる職種の人が真に頭を使うべき課題なのかもしれない。 

Slide 31

Slide 31 text

マルチAZは冗長性の夢を見るか? 　  HPEによるクラウドに依存しないブロックストレージ   参照 : AWS、Azure、GCPのどの仮想マシンからでも iSCSIで... HPE Cloud Volumes    対応するどのクラウドプロバイダからもマウント・iSCSIでアクセス可能なフルマネージドブロックストレージサービス。    2019/11/01から提供開始で、11/02現在AWS・Azureに対応。    GCPなど他プロバイダも後日対応予定。    支払いはプリペイド方式で6万円~ 

Slide 32

Slide 32 text

マルチAZは冗長性の夢を見るか? 　  まとめ 

Slide 33

Slide 33 text

マルチAZは冗長性の夢を見るか? 　  「マルチAZなら大丈夫」ではなく「マルチAZは前提」  ・冗長性や可用性は、マルチAZであることが前提。     ・クラウドプロバイダに頼り切らず、自身でも出来る事は無いか考え、取り組む。    

Slide 34

Slide 34 text

マルチAZは冗長性の夢を見るか? 　  可搬性で可用性を補う  ・負荷分散や障害対策のための構成以外にも、色々な手法で高可用性を実現することが出来る。    ・コンテナ技術で、可搬性をもって可用性を補う事も可能。     ・様々な手法が考えられるが、クラウドネイティブ時代においてはコンテナを用いる手法が適している。  クラウドネイティブ・アーキテクチャ可用性と費用対効果を極める次世代設計の原則 (impress top gear)

Slide 35

Slide 35 text

マルチAZは冗長性の夢を見るか? 　  クラウドプロバイダに依存しない  ・AWSやGCP、Azureなど様々なクラウドプロバイダが溢れており、それぞれ得意なことなど特徴がある。    ・一つのクラウドプロバイダだけに依存せず、ハイブリッドな構成を考えたり、そもそも裏側でどのマシンが利用されるかを意識しない事も可能になりつつある。     ・AWSで組んだ構成を全く同じようにGCPで組む必要は無い。良いとこ取りをし、片方のプロバイダでの障害を別のプロバイダでカバーできるような構成を組む。  

Slide 36

Slide 36 text

マルチAZは冗長性の夢を見るか? 　  謝辞  スライド作成に協力してくれた    ・内村和博様  ・三浦一樹様    本当にありがとうございました！ 

Slide 37

Slide 37 text

マルチAZは冗長性の夢を見るか? 　  ご清聴ありがとうございました。 