My External Storage

Feb 3, 2018 - 6 minute read - Comments - report k8s

[k8s]Cloud Native Developers JP 第3回勉強会 #cndjp3 参加メモ

いつも楽しく学ばせていただいているオラクル早川さん主催のcndjp。 今回は「Kubernetesで実現する高可用性システム」というテーマでKubernetes(k8s)と可用性について、ハンズオンでは実際にk8sとApache Kafkaを使った構成に対して、chaoskubeによるカオスエンジニアリングを行った。
URL https://cnd.connpass.com/event/75617/
会場 オラクル青山センター 13F セミナールーム
日時 2018/01/31(水) 18:30 〜 20:30
ハッシュタグ #cndjp3
資料 Kubernetes × 可用性 – cndjp第3回勉強会

TL;DR

  • マイクロサービスの4層アーキテクチャごとの可用性
  • Kafkaを使ったチャットアプリサービスをk8sにデプロイ
  • chaoskubeを使ってカオステストを実施

マイクロサービス4層アーキテクチャ

Production-Ready Microservicesの著者である、Susan Fowler氏はマイクロサービスを4層アーキテクチャとして定義している。

The Four Layers Of Microservice Architecture

  • マイクロサービス（サービス本体）
  • アプリケーションプラットフォーム（ロギング、監視）
  • 通信（サービス間の通信）
  • ハードウェア

ハードウェア部分をクラウド、サービス間の通信をk8sに任せる。アプリケーションプラットフォーム以上についてもk8sとの組み合わせで高機能・高可用性を実現できる。 高可用性を実現するためには、レイヤー毎に単一障害点（SPOF）を考える必要がある。

単一障害点…システム全体に影響を及ぼす障害。認証とかDBとか。

マイクロサービス層の可用性

マイクロサービスのトレードオフ

マイクロサービスのトレードオフ

マイクロサービスを利用することで開発者はモジュールの分割、個別デプロイなど大きなメリットを得るが、一方で無視できないデメリットも多い。その中の一つとして、サービス境界（サービス間の結合部分）に対する可用性・回復性の担保がある。 マイクロサービスの場合、当然モノリシックな構成よりも個々の機能が分裂されているので、SPOFとなり得る部分が多くなる。

マイクロサービスの設計としては、それらに対してヘルスチェックパターン、、サーキットブレーカーパターンなどを適用して回避する。

他にもバルクヘッドパターンなどがある。

サービスメッシュを使ったサービス境界に対する障害対策

モノリシックなサービスと比較してマイクロサービスの個々のサービスにフォーカスした可用性の担保は簡単になる。
サービス境界に対する可用性の担保はk8sの場合、サービスメッシュを利用すると簡単に導入できる。
サービスメッシュとはサービス間のミドルウェアで、モノリシックなサービスだとnginxがやっているような機能をネットワーク間の処理をいい感じにやってくれるツールの総称。IstioやLinkerdなどがある。（これに関しては次回のcndjpで取り上げていただけるらしい）

ハンズオン1: Apache Kafkaを利用した簡易チャットアプリをk8sにデプロイする

一般的なWeb3層アプリケーションで考えると可用性の担保としてセッションステートの分離、DBの可用構成がある。
k8s上でもセッションステートをアプリから分離してRedisなどで可用性を担保することになる。こうすることでユーザーのセッションをキープしたままサービスの更新などが可能になる。

Apache KafkaはLAMPスタックから置き換わったSMACKスタックを担うOSSである。
2011年にLinkedInから公開されたオープンソースの分散メッセージングシステム。Kafkaによってメッセージの中継を複数のPodで分散して行う。それぞれのPodはお互いにバックアップを取るので、可用性、回復性が実現できる。

ハンズオンではスペック不足？で動かない人が多かったらしいが、自分のMacbook2015は手順通りにやれば特に問題なかった。

アプリケーションプラットフォーム層の可用性

##リリースと可用性 アプリケーションプラットフォーム層の可用性にはリリースも関連してくる。
変更は障害のリスクであり、バグを含んでいないものをミスなくリリースできるCI/CD環境が用意されている必要がある。
Istioなどを利用すればセンシティブなカナリーデプロイメントも可能

Kubernetes層・ハードウェア層の可用性

巨人の肩に乗る

Building High-Availability Clusters

一言でいうと自前で可用性の高いk8sのクラスター構成を用意するのはめちゃくちゃめんどくさい。 ハードウェアにしても自前でマルチゾーン構成を用意するはよほどの資金力が必要。クラウドサービスに頼るのがよさそう。

ハンズオン2: chaoskubeによるランダムなPodのシャットダウン

ハンズオン1で作成したKafkaを利用したチャットアプリに対して、k8s Podをランダムにダウンさせるカオスエンジニアリングを実施した。 k8sのPodに対してカオスエンジニアリングを行うにはchaoskubeがあるようだ。

https://github.com/linki/chaoskube

Macの場合はbrew install httpdでabコマンドが利用できるようになる。 たしかにPodは落ちているのだが、メッセージの欠損なくチャットが継続された。

終わってみて

実は最初の一時間くらいはvagrant上のk8sクラスターが全然起動しなくて（正確にいうとssh接続が出来なくてvagrant upが成功しなくて）、 話をちゃんと聞けていなかった。ベースがなくて初めて聞く事ばかりだし、ちょっと動かなくなるとお手上げになってしまうので、 自己学習が必要だなと感じる。Kodecataとかで勉強しないと。

Learn Kubernetes using Interactive Browser-Based Scenarios

次回はIstio。名前しか知らないのでちょっとでもわかるようになるといいなー。

参考

関連

関連記事