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
DevOps, Immutable Infrastructure, Microservices...
Search
Yoshiori SHOJI
March 22, 2019
Technology
13
2.3k
DevOps, Immutable Infrastructure, Microservices and Chaos Engineering
https://railsdm.github.io/
#railsdm2019
Yoshiori SHOJI
March 22, 2019
Tweet
Share
More Decks by Yoshiori SHOJI
See All by Yoshiori SHOJI
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
340
ソートできるUUID v7をJavaで使うときの話
yoshiori
8
6.8k
Go Down Rockin'
yoshiori
26
12k
テストデータを貯めて感じたこと
yoshiori
12
4.3k
エンジニアリング x US 海外とのコラボレーション
yoshiori
3
2k
未完成な技術と歩む道のりでの 試行錯誤
yoshiori
0
150
Change the recipe's world
yoshiori
3
1.4k
Cookpad awakens
yoshiori
5
7.5k
Failure teaches Success
yoshiori
42
11k
Other Decks in Technology
See All in Technology
短縮URLをお手軽に導入しよう
nakasho
0
110
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
310
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
670
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
230
クラウドサービス事業者におけるOSS
tagomoris
3
950
表現を育てる
kiyou77
1
230
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
150
30分でわかる『アジャイルデータモデリング』
hanon52_
10
2.9k
AI エージェント開発を支える MaaS としての Azure AI Foundry
ryohtaka
6
630
全文検索+セマンティックランカー+LLMの自然文検索サ−ビスで得られた知見
segavvy
2
130
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
1.6k
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
140
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Producing Creativity
orderedlist
PRO
344
39k
Optimizing for Happiness
mojombo
376
70k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
21
2.5k
Into the Great Unknown - MozCon
thekraken
35
1.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
How STYLIGHT went responsive
nonsquared
98
5.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Transcript
DevOps, Immutable Infrastructure, Microservices そして Chaos Engineering Yoshiori Shoji
自己紹介
庄司 嘉織 @yoshiori
さて
Velocity 2009 の Flickr の発表で DevOps が言及されてから 10 年 IUUQTXXXTMJEFTIBSFOFUKBMMTQBXEFQMPZTQFSEBZEFWBOEPQTDPPQFSBUJPOBUqJDLS
Immutable Infrastructure Microservices Docker Kubernetes Chaos Engineering…
個別の話をする事はあるけど 全体の繋がりというか流れを話す事は あまりないので 僕の見てきた世界で語ろうと思う
DevOps
流石に説明はいらないと思うので省略 (ry
二人の Fowler のお話
Immutable Infrastructure ここらへんで 12:35 くらいなら余裕すぎる進行
Immutable Infrastructure •Chad Fowler •とりあえずサーバ弄って 「あとで chef に書いてお くよ!」← 忘れる
•不変にしておく •Blue-Green Deployment IUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM
Blue-Green Deployment •実は 2010 年の時点で Martin Fowler によって提唱されてい た。 •Immutable
Infrastructure の記 事の 3 年前 •ただ主題はサーバの不変性ではな く、デプロイの高速化と安定化、 ロールバックのしやすさなどだっ た。 IUUQTNBSUJOGPXMFSDPNCMJLJ#MVF(SFFO%FQMPZNFOUIUNM
Immutable Infrastructure の話に戻る
Immutable Infrastructure しかし、もっと注目に値するのは、新しいプログ ラミングパラダイムのように、このようにインフ ラストラクチャを考えることによって、私のシス テムをかなり根本的に見る方法が変わることで す。 新しいパターンとアンチパターンが出現します。 デプロイだけでなくアプリケーションコード(そ してチーム構造さえも)について私が考える方法
が変わりつつあります。 IUUQDIBEGPXMFSDPNJNNVUBCMFEFQMPZNFOUTIUNM
僕らはまだその意味をわかっていなかった
Microservices ここらへんで 12:40 くらい?
Microservices •Martin Fowler •超巨大な Monolithic アプ リケーションからの離脱 •小さなサービスに分割し ていく •実は組織パターンの話
IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
実は組織パターンの話 •Conway の法則 •一つのデカいチームでやって もあまり意味がない ‣チームは機能横断(cross- functional)型 ‣DevOps IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
でも急速に流行りすぎた
MicroservicePrerequisites •下記適性に合わないのであれば、マイクロサー ビススタイルを採用すべきではない ‣Rapid provisioning ‣Basic Monitoring 少なくとも技術的な問題について(エラーの発 生回数、サービスの可用性など)は検出できる ようにするべきで、同時にビジネス上の問題
(発注処理の失敗など)をモニタリングするこ とも重要だろう。 ‣Rapid application deployment •Monolithic なシステムでも必要なのでまずは これを整えるべき IUUQTNBSUJOGPXMFSDPNCMJLJ.JDSPTFSWJDF1SFSFRVJTJUFTIUNM
ちゃんとまずは Monolithic で頑張るの大事
例のアレ •20000+ specs, •1700+ models •50+ developers •技術の力でちゃんと何とかする ‣rrrspec ‣mamiya
IUUQTTQFBLFSEFDLDPNB@NBUTVEBUIFSFDJQFGPSUIFXPSMETMBSHFTUSBJMTNPOPMJUI
そして 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 は自作
•サービスの通信の状況把握 •タイムアウト・リトライ・サー キットブレーカーをアプリケー ションからはがす
None
他にもサービス間通信をテストしようとした。 Pact という Consumer-Driven Contract testing のツールを使って。
複雑になったアプリケーションの変更時の 影響範囲を知るためにテストを書くように 複雑になったサービス間通信の変更時も 影響範囲がわかるようにテストを書こうとした。 けど結局やめた(主に開発スピードとのミスマッチ)
Chaos Engineering ここらへんで 12:55 くらいだとギリ全部話せる
Chaos Engineering •分散システムにおいてシステムが不安定 な状態に耐えることの出来る環境を構築 するための検証の規律です •サーバを落す事ではない ‣多分最初に出た Netflix の Chaos
Monkey の印象が強すぎてそう思ってい る人が多い ‣このコンテナ時代にインスタンス一個落 しても何もあまり得る物はない IUUQTQSJODJQMFTPGDIBPTPSH
Steady State •そのサービスの定常状態を計測出来るよう にする •Netflix では ‣毎秒どのくらいのユーザーが動画を見始めた か ‣毎秒どのくらいのユーザーがサインアップし た
•Cookpadでは ‣レシピ閲覧数と検索数の比 IUUQTUFDIMJGFDPPLQBEDPNFOUSZ
IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF
IUUQTTQFBLFSEFDLDPNJULRBMJGFPGDIBPTFOHJOFFSJOHTUBSUJOHXJUISFTJMJFODF TMJEF
まずは Staging 環境で 本番と同じメッシュ構造を構築し、 サービス間通信に障害を起こし影響を見る。 というのが Envoy 導入したのでやりやすい
サービス間通信の変更時に異常が起きない ように過剰にテストを書くのではなく、 もしサービス間通信に異常があった場合に どうなるのかを把握し影響範囲を最小限に 出来るようにしておく
Microservices •実は最初の Microservices の記事に 書いてある •マイクロサービスを採用するチームは サービスがユーザ体験に与える影響に ついて絶えず検討します。 •NetflixのSimian Armyは、アプリ
ケーションの耐久性と監視についてテ ストするために、勤務時間内にサービ スやデータセンタさえに対しても障害 を誘発させます。 IUUQTNBSUJOGPXMFSDPNBSUJDMFTNJDSPTFSWJDFTIUNM
はい 時間余ったら喋る カナリア XaaS
というような事を考えたり話したりするのが 好きな人間です。 以上自己紹介でした。