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.6k
マルチ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
QA環境で誰でも自由自在に現在時刻を操って検証できるようにした話
kalibora
1
120
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
1.3k
情報漏洩させないための設計
kubotak
5
1.2k
traP の部内 ISUCON とそれを支えるポータル / PISCON Portal
ikura_hamu
0
140
Fibonacci Function Gallery - Part 1
philipschwarz
PRO
0
270
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
200
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
900
「とりあえず動く」コードはよい、「読みやすい」コードはもっとよい / Code that 'just works' is good, but code that is 'readable' is even better.
mkmk884
6
1.3k
Go の GC の不得意な部分を克服したい
taiyow
3
990
Jaspr Dart Web Framework 박제창 @Devfest 2024
itsmedreamwalker
0
140
Compose UIテストを使った統合テスト
hiroaki404
0
120
テストケースの名前はどうつけるべきか?
orgachem
PRO
1
180
Featured
See All Featured
Scaling GitHub
holman
459
140k
A Philosophy of Restraint
colly
203
16k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Done Done
chrislema
182
16k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
112
50k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
The Pragmatic Product Professional
lauravandoore
32
6.4k
How to Ace a Technical Interview
jacobian
276
23k
Code Reviewing Like a Champion
maltzj
521
39k
Raft: Consensus for Rubyists
vanstee
137
6.7k
It's Worth the Effort
3n
183
28k
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は冗長性の夢を見るか? ご清聴ありがとうござ いました。