Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マルチAZは冗長性の夢を見るか? / Do Multi-AZ Dream of Redunda...
Search
cidr
November 02, 2019
Programming
2
1.5k
マルチAZは冗長性の夢を見るか? / Do Multi-AZ Dream of Redundancy?
JAWS Festa 2019 SAPPOROで発表したスライド
cidr
November 02, 2019
Tweet
Share
Other Decks in Programming
See All in Programming
カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?
asayamakk
3
1.1k
『ドメイン駆動設計をはじめよう』のモデリングアプローチ
masuda220
PRO
4
150
いかにして不足・不整合なくデータ移行したか
tjmtmmnk
1
1k
ピクシブ百科事典のWebフロントエンドパフォーマンス改善
higara
0
230
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
d_endo
1
950
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
440
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
4
2.8k
シールドクラスをはじめよう / Getting Started with Sealed Classes
mackey0225
3
350
Universal Linksの実装方法と陥りがちな罠
kaitokudou
1
220
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
50
31k
PLoP 2024: The evolution of the microservice architecture pattern language
cer
PRO
0
1.1k
現場で役立つモデリング 超入門
masuda220
PRO
12
2.6k
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Navigating Team Friction
lara
183
14k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
StorybookのUI Testing Handbookを読んだ
zakiyama
26
5.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
We Have a Design System, Now What?
morganepeng
50
7.2k
4 Signs Your Business is Dying
shpigford
180
21k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Building an army of robots
kneath
302
42k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
KATA
mclloyd
29
13k
Transcript
マルチAZは 冗長性の夢を見るか? 西田 龍斗 (@cidr_cuckooo) JAWS FESTA 2019 SAPPORO
自己紹介 ・西田 龍斗(にしだ りゅうと) - Twitter @cidr_cuckooo ・経歴
- 2019年1月に個人事業主として開業 - 2019年3月に釧路高専3年次退学 以後フリーランスプログラマとしてアプリ ケーション開発に携わる。
マルチAZは冗長性の夢を見るか? マルチAZ構成 組んでますか?
マルチAZは冗長性の夢を見るか? 参照 : 東京リージョン(AP-NORTHEAST-1)で発生した..
マルチAZは冗長性の夢を見るか? 東京リージョン内単一のAZであるapne-az4というIDのAZで発生。 複数のAZを併用する「マルチAZ構成」を組んでいれば影響を避ける事が出来た障害 であったため、SNSやネットメディアではマルチAZを推奨する意見が多く見られた。 参照 : 東京リージョン(AP-NORTHEAST-1)で発生した..
マルチAZは冗長性の夢を見るか? マルチAZは有効だった! どんどんマルチAZ構成を 使っていこう!
スライドショーの最後です。クリックすると終了します。
マルチAZは冗長性の夢を見るか? 本当に??
マルチAZは冗長性の夢を見るか? マルチAZ構成は有効ではあるが・・・ よく考えると ・運が悪く複数のAZで同時に障害が起きるかもしれない ・大規模災害時には複数AZやリージョン単位で被害を被るかもしれない
・AWSがハッキングされて利用出来なくなるかもしれない ・某国から飛んできたミサイルがどこかのデータセンタに落ちるかもしれない ・そもそもマルチAZでも防げなかった状況も
マルチAZは冗長性の夢を見るか? Q : ここまで考えるのは過剰じゃないか? A : 障害対策・災害対策は楽観的に考えない!
BGPが間違った経路情報を流したり、全DNSがダウンしたりでインターネットが崩壊し た時とかは流石に諦める・・・
マルチAZは冗長性の夢を見るか? そもそもマルチAZ構成は 大前提です。
マルチAZは冗長性の夢を見るか? 提供しているアプリケーションに対して、ある程度は自身で可用性を担保 できる仕組みを作るべき。 ・でもマルチリージョンとかハイブリットクラウドは費用が沢山かかる ・コールドスタンバイを組んだ所で、通常時は動かないなら無駄に思えるし、予備も落ちたら意 味がない
・そもそもどうすれば良いのか分からない
マルチAZは冗長性の夢を見るか? サービスが停止したら、 すぐに別の場所で運用開始 できるような設計を組む。
マルチAZは冗長性の夢を見るか? そうだ。 コンテナ使おう。
マルチAZは冗長性の夢を見るか? コンテナはいいぞ ・1つのアプリケーションを1個のコンテナに閉じ込めていろんな所で再利用できる。移植が簡単 ・ミドルウェアや依存ライブラリを閉じ込めることが出来るのでホストの環境が汚れない ・環境をコードで管理するので、バージョン管理が可能になり、ヒューマンエラーも減る
・何台マシンがあろうとコード一つで簡単に展開できる ・コンテナやコンテナオーケストレーション、その他周辺サービス群が成熟している
マルチAZは冗長性の夢を見るか? Why Containers?
マルチAZは冗長性の夢を見るか? 一般的なマルチAZ構成で得られる可用性(Availability)
マルチAZは冗長性の夢を見るか? コンテナ技術による可搬性(Portability)
マルチAZは冗長性の夢を見るか? 可搬性で可用性を補う インフラ・AZ・リージョン障害があっても、別の正常なマシンですぐにサービスを提供できる。
マルチAZは冗長性の夢を見るか? 可搬性で可用性を補う アプリケーション障害(バグ・脆弱性)があった場合、そのバージョンのアプリをローカルで検証できる。
マルチAZは冗長性の夢を見るか? 可搬性で可用性を補う スケーリングが容易になる。(AutoScalingとの親和性が高い)
マルチAZは冗長性の夢を見るか? コンテナ オーケストレーション
マルチAZは冗長性の夢を見るか? Kubernetesを使う 発音は「クーべネティス」?「クーバネティス」? 省略してK8s「ケーエイツ」と呼ぶことも。 K8sのゴールは可搬性・拡張性・自己修復を提供し、サービス運用負担を減らすためエコシス テムを整備していくこととなっているので、今回強調したい「可搬性によって可用性を担保す
る」についても適している。 KubernetesはGoogleがかつて「Borg」として、社内向けに開発したコンテナ オーケストレーションツール。 デプロイからコンテナ運用の自動化、セルフヒーリングといったコンテナ開 発を支える複数の機能を持つ。
マルチAZは冗長性の夢を見るか? Docker-Swarmを使う Swarmじゃ出来ない事の例として、依存関係にそってコンテナの立ち上げが出来ないが、 Docker-Swarm + Docker-Composeで解決できるように、Dockerのエコシステムフル活用で Kubernetesと遜色なく利用することが出来る。
ちなみにDocker-Composeもコンテナオーケストレーションツールとして分類される。 Docker-SwarmはDocker公式で提供されているコンテナオーケストレー ションツール。 Kubernetesと比較し、出来る事は少ないものの学習コストはその分低く、 Swarmが持つ機能だけでも十分な事もある。
マルチAZは冗長性の夢を見るか? しかし・・・ Docker-SwarmはKubernetesよりシンプル。 だが、利用者が少なくドキュメントもK8sほど整っているわけではない。 マネージドサービスに至っては皆無なので捉えようによってはK8sより学習コストが高くなることも。 Kubernetesは複雑で学習コストが高い。
クラウドのK8sマネージドサービスは利便性も高く、各クラウドプロバイダでサービスネイティブに扱え るが、そのクラウドプロバイダ内でしか利用できない。 GCPのAnthosはハイブリッドクラウドに対応はしているものの、AnthosでAWSを利用しようとすると EKSほどAWSネイティブには活用できない。
マルチAZは冗長性の夢を見るか? 重要なのはクラウドプロバイダそのものを意識せず扱える構成 クラウドプロバイダやオンプレミスといった事を開発側が意識せずに扱える構成を組む事で 「可搬性による可用性の担保」を出来る環境が整う。
マルチAZは冗長性の夢を見るか? マネージドサービスを使わない選択肢 クラウドプロバイダを意識しない、クラウドプロバイダに依存しないとなると、マネージドサービスを用 いないという選択肢が生まれる。 マネージドサービスを使うことは、コスト負担減や利便性の向上など、沢山のメリットがある反面、クラ ウドプロバイダへの依存度が上がる。
これは運用スタイルをプロバイダに合わせる必要があったり、障害時の復旧やダウンタイムなどがコ ントロール出来なくなる。 その他にも、各プロバイダ得意とする分野があるのに対し、多くをマネージドで構成するとプロバイダ 間の連携を取る事も難しくなる。
マルチAZは冗長性の夢を見るか? Rancher等のようなKubernetes as a Service(KaaS)を使う Rancherを使うと、Kubernetesクラスタとして EKSやGKEといった各クラウドプロバイダの提供する Kubernetesマネージドツールを選択できる。
Kubernetesが目指す目標の中に可搬性がある。 これはまさに、裏で動くマシンがプロバイダのものか、オンプレなのか関係なくどこでも動かせる事が 目的になっている。 しかし実際にそれをやろうとすると学習コストがかかる。 それを補うため生まれた概念がKubernetes as a Service。 題にあるが、RancherはKaaSの一つで、コンテナオーケストレーションツールでもある。
マルチAZは冗長性の夢を見るか? 課題
マルチAZは冗長性の夢を見るか? データの保存 コンテナを扱う場合、データの永続化やバックアップ、ストレージ・DBと、注意を払わなければいけな い所が生まれてくる。 アプリケーションの可用性(可搬性)は担保できても、データそのものの可用性(可搬性)を担保するの は難しい。 CAP定理と呼ばれ、「一貫性・可用性・ネットワーク分断耐性」の3つの特性の内、DBは2つまでしか持
てないのかという長年の研究テーマにもなっている。 プログラマやシステムエンジニアと呼ばれる職種の人が 真に頭を使うべき課題なのかもしれない。
マルチAZは冗長性の夢を見るか? HPEによるクラウドに依存しないブロックストレージ 参照 : AWS、Azure、GCPのどの仮想マシンからでも iSCSIで... HPE Cloud
Volumes 対応するどのクラウドプロバイダからもマウント・iSCSIでアクセス可能なフルマネージ ドブロックストレージサービス。 2019/11/01から提供開始で、11/02現在AWS・Azureに対応。 GCPなど他プロバイダも後日対応予定。 支払いはプリペイド方式で6万円~
マルチAZは冗長性の夢を見るか? まとめ
マルチAZは冗長性の夢を見るか? 「マルチAZなら大丈夫」ではなく「マルチAZは前提」 ・冗長性や可用性は、マルチAZであることが前提。 ・クラウドプロバイダに頼り切らず、自身でも出来る事は無いか考え、取り組む。
マルチAZは冗長性の夢を見るか? 可搬性で可用性を補う ・負荷分散や障害対策のための構成以外にも、色々な手法で高可用性を実現することが出来 る。 ・コンテナ技術で、可搬性をもって可用性を補う事も可能。 ・様々な手法が考えられるが、クラウドネイティブ時代においてはコンテナを用いる手法が適し
ている。 クラウドネイティブ・アーキテクチャ 可用性と費用対効果を極 める次世代設計の原則 (impress top gear)
マルチAZは冗長性の夢を見るか? クラウドプロバイダに依存しない ・AWSやGCP、Azureなど様々なクラウドプロバイダが溢れており、それぞれ得意なことなど特徴があ る。 ・一つのクラウドプロバイダだけに依存せず、ハイブリッドな構成を考えたり、そもそも裏側でどのマ シンが利用されるかを意識しない事も可能になりつつある。
・AWSで組んだ構成を全く同じようにGCPで組む必要は無い。良いとこ取りをし、片方のプロバイダで の障害を別のプロバイダでカバーできるような構成を組む。
マルチAZは冗長性の夢を見るか? 謝辞 スライド作成に協力してくれた ・内村和博様 ・三浦一樹様 本当にありがとうございました!
マルチAZは冗長性の夢を見るか? ご清聴ありがとうござ いました。