Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps, Immutable Infrastructure, Microservices and Chaos Engineering

DevOps, Immutable Infrastructure, Microservices and Chaos Engineering

Yoshiori SHOJI

March 22, 2019
Tweet

More Decks by Yoshiori SHOJI

Other Decks in Technology

Transcript

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

    View Slide

  2. 自己紹介

    View Slide

  3. 庄司 嘉織
    @yoshiori

    View Slide

  4. さて

    View Slide

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

    View Slide

  6. Immutable Infrastructure
    Microservices
    Docker
    Kubernetes

    Chaos Engineering…

    View Slide

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

    View Slide

  8. DevOps

    View Slide

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

    View Slide

  10. 二人の Fowler のお話

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. Immutable Infrastructure の話に戻る

    View Slide

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

    View Slide

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

    View Slide

  17. Microservices
    ここらへんで 12:40 くらい?

    View Slide

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

    View Slide

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

    View Slide

  20. でも急速に流行りすぎた

    View Slide

  21. MicroservicePrerequisites
    •下記適性に合わないのであれば、マイクロサー
    ビススタイルを採用すべきではない
    ‣Rapid provisioning
    ‣Basic Monitoring

    少なくとも技術的な問題について(エラーの発
    生回数、サービスの可用性など)は検出できる
    ようにするべきで、同時にビジネス上の問題
    (発注処理の失敗など)をモニタリングするこ
    とも重要だろう。
    ‣Rapid application deployment
    •Monolithic なシステムでも必要なのでまずは
    これを整えるべき
    IUUQTNBSUJOGPXMFSDPNCMJLJ.JDSPTFSWJDF1SFSFRVJTJUFTIUNM

    View Slide

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

    View Slide

  23. 例のアレ
    •20000+ specs,
    •1700+ models
    •50+ developers
    •技術の力でちゃんと何とかする
    ‣rrrspec
    ‣mamiya
    [email protected]PMJUI

    View Slide

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

    View Slide

  25. Docker

    View Slide

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

    View Slide

  27. ホントだった!!!

    View Slide

  28. Container Orchestration

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  34. View Slide

  35. 他にもサービス間通信をテストしようとした。

    Pact という Consumer-Driven Contract
    testing のツールを使って。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. Steady State
    •そのサービスの定常状態を計測出来るよう
    にする
    •Netflix では
    ‣毎秒どのくらいのユーザーが動画を見始めた

    ‣毎秒どのくらいのユーザーがサインアップし

    •Cookpadでは
    ‣レシピ閲覧数と検索数の比
    IUUQTUFDIMJGFDPPLQBEDPNFOUSZ

    View Slide

  40. IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF

    View Slide

  41. IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide