https://railsdm.github.io/
#railsdm2019
DevOps,Immutable Infrastructure,Microservicesそして Chaos EngineeringYoshiori Shoji
View Slide
自己紹介
庄司 嘉織@yoshiori
さて
Velocity 2009 の Flickr の発表でDevOps が言及されてから 10 年IUUQTXXXTMJEFTIBSFOFUKBMMTQBXEFQMPZTQFSEBZEFWBOEPQTDPPQFSBUJPOBUqJDLS
Immutable InfrastructureMicroservicesDockerKubernetes Chaos Engineering…
個別の話をする事はあるけど全体の繋がりというか流れを話す事はあまりないので僕の見てきた世界で語ろうと思う
DevOps
流石に説明はいらないと思うので省略(ry
二人の Fowler のお話
Immutable Infrastructureここらへんで 12：35 くらいなら余裕すぎる進行
Immutable Infrastructure•Chad Fowler•とりあえずサーバ弄って「あとで chef に書いておくよ!」← 忘れる•不変にしておく•Blue-Green DeploymentIUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM
Blue-Green Deployment•実は 2010 年の時点で MartinFowler によって提唱されていた。•Immutable Infrastructure の記事の 3 年前•ただ主題はサーバの不変性ではなく、デプロイの高速化と安定化、ロールバックのしやすさなどだった。IUUQTNBSUJOGPXMFSDPNCMJLJ#MVF(SFFO%FQMPZNFOUIUNM
Immutable Infrastructure の話に戻る
Immutable Infrastructureしかし、もっと注目に値するのは、新しいプログラミングパラダイムのように、このようにインフラストラクチャを考えることによって、私のシステムをかなり根本的に見る方法が変わることです。新しいパターンとアンチパターンが出現します。デプロイだけでなくアプリケーションコード（そしてチーム構造さえも）について私が考える方法が変わりつつあります。IUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM
僕らはまだその意味をわかっていなかった
Microservicesここらへんで 12：40 くらい?
Microservices•Martin Fowler•超巨大な Monolithic アプリケーションからの離脱•小さなサービスに分割していく•実は組織パターンの話IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
実は組織パターンの話•Conway の法則•一つのデカいチームでやってもあまり意味がない‣チームは機能横断(cross-functional)型‣DevOpsIUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
でも急速に流行りすぎた
MicroservicePrerequisites•下記適性に合わないのであれば、マイクロサービススタイルを採用すべきではない‣Rapid provisioning‣Basic Monitoring 少なくとも技術的な問題について（エラーの発生回数、サービスの可用性など）は検出できるようにするべきで、同時にビジネス上の問題（発注処理の失敗など）をモニタリングすることも重要だろう。‣Rapid application deployment•Monolithic なシステムでも必要なのでまずはこれを整えるべきIUUQTNBSUJOGPXMFSDPNCMJLJ.JDSPTFSWJDF1SFSFRVJTJUFTIUNM
ちゃんとまずは Monolithic で頑張るの大事
例のアレ•20000+ specs,•1700+ models•50+ developers•技術の力でちゃんと何とかする‣rrrspec‣mamiya[email protected]PMJUI
そして Microservice へ……ここらへんで 12：45 くらいだと順調
Docker
Docker•Application も Immutableを意識する事を強制‣ファイルをサーバにアップロードさせないとか‣雑なキャッシュや学習結果もサーバに置いておかないとか
ホントだった!!!
Container Orchestration
Container Orchestration•K8s や ECS•アプリケーションの実行を抽象化(docker run)‣アプリケーション毎にサーバを構築するのではなく、コンテナ実行環境の管理と運用をする‣Microservice 化によって多数のコンテナ化されたアプリケーションを管理しなくてはいけなくなった。
Microservice + Container•microservice 化によって個々のサービスの小型化•Docker でアプリケーションのポータビリティの向上•Cookpad では 70+ のアプリケーションが協調して動く•各サービスは単純でもシステム全体としては複雑になる
たくさんのアプリを動かすのは技術的に解決出来ているたくさんのアプリをうまく繋げる事に課題が出てきたサービス間通信なんとかしたい
ServiceMeshここらへんで 12：50 くらいだと間にあう
ServiceMesh•Cookpad では data-plane として Envoy を採用し、control-plane は自作•サービスの通信の状況把握•タイムアウト・リトライ・サーキットブレーカーをアプリケーションからはがす
他にもサービス間通信をテストしようとした。 Pact という Consumer-Driven Contracttesting のツールを使って。
複雑になったアプリケーションの変更時の影響範囲を知るためにテストを書くように複雑になったサービス間通信の変更時も影響範囲がわかるようにテストを書こうとした。けど結局やめた(主に開発スピードとのミスマッチ)
Chaos Engineeringここらへんで 12：55 くらいだとギリ全部話せる
Chaos Engineering•分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律です•サーバを落す事ではない‣多分最初に出た Netflix の ChaosMonkey の印象が強すぎてそう思っている人が多い‣このコンテナ時代にインスタンス一個落しても何もあまり得る物はないIUUQTQSJODJQMFTPGDIBPTPSH
Steady State•そのサービスの定常状態を計測出来るようにする•Netflix では‣毎秒どのくらいのユーザーが動画を見始めたか‣毎秒どのくらいのユーザーがサインアップした•Cookpadでは‣レシピ閲覧数と検索数の比IUUQTUFDIMJGFDPPLQBEDPNFOUSZ
IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF
まずは Staging 環境で本番と同じメッシュ構造を構築し、サービス間通信に障害を起こし影響を見る。というのが Envoy 導入したのでやりやすい
サービス間通信の変更時に異常が起きないように過剰にテストを書くのではなく、もしサービス間通信に異常があった場合にどうなるのかを把握し影響範囲を最小限に出来るようにしておく
Microservices•実は最初の Microservices の記事に書いてある•マイクロサービスを採用するチームはサービスがユーザ体験に与える影響について絶えず検討します。•NetflixのSimian Armyは、アプリケーションの耐久性と監視についてテストするために、勤務時間内にサービスやデータセンタさえに対しても障害を誘発させます。IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
はい時間余ったら喋るカナリアXaaS
というような事を考えたり話したりするのが好きな人間です。以上自己紹介でした。
yoshiori
doradora09
you
takahia1988
niryuu
yu4u
newrelic2023
gotok365
alexanderbyndyu
mii3king
yoyakoba
kawaguti
dotmariusz
jakevdp
garrettdimon
sferik
lemiorhan
colly
kevinliebholz
paulrobertlloyd
caitiem20
zenorocha
deanohume
moore