DevOps, Immutable Infrastructure, Microservices and Chaos Engineering

Slide 1

Slide 1 text

DevOps, Immutable Infrastructure, Microservices そして Chaos Engineering Yoshiori Shoji

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

庄司嘉織 @yoshiori

Slide 4

Slide 4 text

さて

Slide 5

Slide 5 text

Velocity 2009 の Flickr の発表で DevOps が言及されてから 10 年 IUUQTXXXTMJEFTIBSFOFUKBMMTQBXEFQMPZTQFSEBZEFWBOEPQTDPPQFSBUJPOBUqJDLS

Slide 6

Slide 6 text

Immutable Infrastructure Microservices Docker Kubernetes  Chaos Engineering…

Slide 7

Slide 7 text

個別の話をする事はあるけど全体の繋がりというか流れを話す事はあまりないので僕の見てきた世界で語ろうと思う

Slide 8

Slide 8 text

DevOps

Slide 9

Slide 9 text

流石に説明はいらないと思うので省略 (ry

Slide 10

Slide 10 text

二人の Fowler のお話

Slide 11

Slide 11 text

Immutable Infrastructure ここらへんで 12：35 くらいなら余裕すぎる進行

Slide 12

Slide 12 text

Immutable Infrastructure •Chad Fowler •とりあえずサーバ弄って「あとで chef に書いておくよ!」← 忘れる •不変にしておく •Blue-Green Deployment IUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM

Slide 13

Slide 13 text

Blue-Green Deployment •実は 2010 年の時点で Martin Fowler によって提唱されていた。 •Immutable Infrastructure の記事の 3 年前 •ただ主題はサーバの不変性ではなく、デプロイの高速化と安定化、ロールバックのしやすさなどだった。 IUUQTNBSUJOGPXMFSDPNCMJLJ#MVF(SFFO%FQMPZNFOUIUNM

Slide 14

Slide 14 text

Immutable Infrastructure の話に戻る

Slide 15

Slide 15 text

Immutable Infrastructure しかし、もっと注目に値するのは、新しいプログラミングパラダイムのように、このようにインフラストラクチャを考えることによって、私のシステムをかなり根本的に見る方法が変わることです。新しいパターンとアンチパターンが出現します。デプロイだけでなくアプリケーションコード（そしてチーム構造さえも）について私が考える方法が変わりつつあります。 IUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM

Slide 16

Slide 16 text

僕らはまだその意味をわかっていなかった

Slide 17

Slide 17 text

Microservices ここらへんで 12：40 くらい?

Slide 18

Slide 18 text

Microservices •Martin Fowler •超巨大な Monolithic アプリケーションからの離脱 •小さなサービスに分割していく •実は組織パターンの話 IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM

Slide 19

Slide 19 text

実は組織パターンの話 •Conway の法則 •一つのデカいチームでやってもあまり意味がない ‣チームは機能横断(cross- functional)型 ‣DevOps IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM

Slide 20

Slide 20 text

でも急速に流行りすぎた

Slide 21

Slide 21 text

MicroservicePrerequisites •下記適性に合わないのであれば、マイクロサービススタイルを採用すべきではない ‣Rapid provisioning ‣Basic Monitoring  少なくとも技術的な問題について（エラーの発生回数、サービスの可用性など）は検出できるようにするべきで、同時にビジネス上の問題（発注処理の失敗など）をモニタリングすることも重要だろう。 ‣Rapid application deployment •Monolithic なシステムでも必要なのでまずはこれを整えるべき IUUQTNBSUJOGPXMFSDPNCMJLJ.JDSPTFSWJDF1SFSFRVJTJUFTIUNM

Slide 22

Slide 22 text

ちゃんとまずは Monolithic で頑張るの大事

Slide 23

Slide 23 text

例のアレ •20000+ specs, •1700+ models •50+ developers •技術の力でちゃんと何とかする ‣rrrspec ‣mamiya IUUQTTQFBLFSEFDLDPNB@NBUTVEBUIFSFDJQFGPSUIFXPSMETMBSHFTUSBJMTNPOPMJUI

Slide 24

Slide 24 text

そして Microservice へ…… ここらへんで 12：45 くらいだと順調

Slide 25

Slide 25 text

Docker

Slide 26

Slide 26 text

Docker •Application も Immutable を意識する事を強制 ‣ファイルをサーバにアップロードさせないとか ‣雑なキャッシュや学習結果もサーバに置いておかないとか

Slide 27

Slide 27 text

ホントだった!!!

Slide 28

Slide 28 text

Container Orchestration

Slide 29

Slide 29 text

Container Orchestration •K8s や ECS •アプリケーションの実行を抽象化 (docker run) ‣アプリケーション毎にサーバを構築するのではなく、コンテナ実行環境の管理と運用をする ‣Microservice 化によって多数のコンテナ化されたアプリケーションを管理しなくてはいけなくなった。

Slide 30

Slide 30 text

Microservice + Container •microservice 化によって個々のサービスの小型化 •Docker でアプリケーションのポータビリティの向上 •Cookpad では 70+ のアプリケーションが協調して動く •各サービスは単純でもシステム全体としては複雑になる

Slide 31

Slide 31 text

たくさんのアプリを動かすのは技術的に解決出来ているたくさんのアプリをうまく繋げる事に課題が出てきたサービス間通信なんとかしたい

Slide 32

Slide 32 text

ServiceMesh ここらへんで 12：50 くらいだと間にあう

Slide 33

Slide 33 text

ServiceMesh •Cookpad では data-plane として Envoy を採用し、 control-plane は自作 •サービスの通信の状況把握 •タイムアウト・リトライ・サーキットブレーカーをアプリケーションからはがす

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

他にもサービス間通信をテストしようとした。  Pact という Consumer-Driven Contract testing のツールを使って。

Slide 36

Slide 36 text

複雑になったアプリケーションの変更時の影響範囲を知るためにテストを書くように複雑になったサービス間通信の変更時も影響範囲がわかるようにテストを書こうとした。けど結局やめた(主に開発スピードとのミスマッチ)

Slide 37

Slide 37 text

Chaos Engineering ここらへんで 12：55 くらいだとギリ全部話せる

Slide 38

Slide 38 text

Chaos Engineering •分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律です •サーバを落す事ではない ‣多分最初に出た Netﬂix の Chaos Monkey の印象が強すぎてそう思っている人が多い ‣このコンテナ時代にインスタンス一個落しても何もあまり得る物はない IUUQTQSJODJQMFTPGDIBPTPSH

Slide 39

Slide 39 text

Steady State •そのサービスの定常状態を計測出来るようにする •Netﬂix では ‣毎秒どのくらいのユーザーが動画を見始めたか ‣毎秒どのくらいのユーザーがサインアップした •Cookpadでは ‣レシピ閲覧数と検索数の比 IUUQTUFDIMJGFDPPLQBEDPNFOUSZ

Slide 40

Slide 40 text

IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF

Slide 41

Slide 41 text

IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF

Slide 42

Slide 42 text

まずは Staging 環境で本番と同じメッシュ構造を構築し、サービス間通信に障害を起こし影響を見る。というのが Envoy 導入したのでやりやすい

Slide 43

Slide 43 text

サービス間通信の変更時に異常が起きないように過剰にテストを書くのではなく、もしサービス間通信に異常があった場合にどうなるのかを把握し影響範囲を最小限に出来るようにしておく

Slide 44

Slide 44 text

Microservices •実は最初の Microservices の記事に書いてある •マイクロサービスを採用するチームはサービスがユーザ体験に与える影響について絶えず検討します。 •NetﬂixのSimian Armyは、アプリケーションの耐久性と監視についてテストするために、勤務時間内にサービスやデータセンタさえに対しても障害を誘発させます。 IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM

Slide 45

Slide 45 text

はい時間余ったら喋るカナリア XaaS

Slide 46

Slide 46 text

というような事を考えたり話したりするのが好きな人間です。以上自己紹介でした。