Cookpad awakens

1.

$PPLQBEBXBLFOT ঙ࢘Յ৫ ∠

2.

ঙ࢘Յ৫ yoshiori ٕज़෦௕ਓࣄ෦௕ ∠

3.

ਓࣄ෦௕ バックオフィスでも技術が分かる人がいることが大事  エンジニアの採用にも、もちろん大事エンジニア以外に人権が無いのではない逆に変に神聖視されないためにも大事

4.

ٕज़෦௕

5.

࠷ॳ쎂

6.

まだまだいっぱい

7.

쎿썗쏝쏃쎅෼ׂ썿࿈ܞ

8.

쎿썗쏝쏃쎅෼ׂ썿࿈ܞ microservices化によってサービス間の連携が大事になった。サービス間の境界に対して Pact と Expeditor というのを使っている -障害を制御する
Expeditor -障害を予防する Pact

9.

&YQFEJUPS -サーキットブレイカー -並列リクエスト -リトライ制御 cookpad/expeditor

10.

1BDU -サービス間の連携部分のテスト -簡単に言うと Service-A が返す JSON と   Service-B が期待する
JSON のテスト -Consumer-Driven Contract testing   (CDC testing) - 詳しくは http://techlife.cookpad.com/entry/2016/06/28/164247

11.

QBDU@KVOJU@GPSNBUUFS -規模が大きいアプリケーションでは、pact verification が失敗した時に出力が多く見づらい -JUnit のフォーマットにすることで CI などでも見やすいようにするプラグイン taiki45/pact_junit_formatter

12.

QBDU@FYQFDUBUJPOT -Remote Facade のテストでのみ Pact を使い、その他の層では Remote Facade をモックするように
-Pact の expectation をレスポンスとして流用できる -ちゃんと設定したものが両方で呼ばれていることも確認できる yoshiori/pact_expectations

13.

1IBLDIJ -iOS からの API 呼び出しも -Pact の expectation を楽に記述できる -Swift
製 -XCTest から利用 cookpad/Phakchi

14.

쎿썗쏝쏃쎅 쏧썗쏉쏝쏴쏐쎭 分割したサービスは全て Docker 化されている Docker を更に有効的に使うために hako を作った

15.

IBLP

16.

IBLP -Docker のデプロイツール - 今のところ ECS に対応 - 定義は YAML
で記述  （Ruby DSL とかは無い） eagletmt/hako

17.

-一昨年から新規はすべて Docker、既存のものもどんどん Docker 化は結構進んでいた。 -が、どうしてもインフラ作業などは発生する。 - アプリケーションサーバ以外の機能  （RDS、Route53、ELB などなどの設定）
- 環境変数の追加など  （DB 情報や APIのキーなどの秘匿値） IBLP

18.

IBLP -定義は YAML で記述 -ソフトウェアと同様に開発者が管理ができ、 git&github 等で管理、レビューが出来る -cookpad では hako_apps
というリポジトリで集中管理してる

19.

IBLP -秘匿値を含む環境変数の扱い - etcd をバックエンドにした etcvault を使用 - 現在 hashicorp/vault
に移行中 sorah/etcvault

20.

-デプロイに処理を差し込む - Route53 の自動設定やデプロイするリビジョンを jenkins から取得等 -詳しくは下記 - https://speakerdeck.com/eagletmt/ecs-woli-yong-sitadepuroihuan-
jing - http://techlife.cookpad.com/entry/2016/09/09/235007 IBLP

21.

-hako deploy - デプロイを実行するコマンド - クックパッドではコマンド実行に Rundeck を使用 -hako
oneshot - バッチ系 IBLP

22.

LVSPLP

23.

-ジョブ管理システム - 各チームのジョブスケジュールを  可視化する機能などもあり -Ruby で書かれてる -Web UI がある -細かい話は
http://techlife.cookpad.com/entry/2015/12/07/195732 LVSPLP cookpad/kuroko2

24.

-ジョブ管理を最初は cron で雑に管理していて破綻する - どのサーバでやるか - リソース使い切って分散したくなったり - バッチ用のサーバ立てたり
쏂쏱쏠쎂썻썛썽

25.

-DB への接続やドメイン特有の処理など  Web アプリと共有したいものは多い -普通にやると job 実行は web アプリを内包しなきゃいけなくなる
- デプロイが別になったり大変 - プロビジョニング自動化してても大変…… - ワーカーは最強の権限をもったサーバになりがち 쏂쏱쏠쎂썻썛썽

26.

-hako oneshot - ECS task なので IAM role を設定できる -
権限管理や秘匿値の管理がコンテナ単位になって適切にサービス毎に権限が管理できる - デプロイを気にする必要ない  （Dokcer イメージを hako で実行するため） 쏂쏱쏠쎂썻썛썽

27.

#BSCFRVF

28.

-ジョブキューシステム -Ruby で書かれてる -kuroko2 と同じような Web UI -細かい話は   https://speakerdeck.com/k0kubun/scalable-job-queue-system-built-
with-docker #BSCFRVF cookpad/barbeque

29.

-Rails だと Resque や Sidekiq 使うことが多い -さらにキューの管理が複雑に -起動がユーザリクエスト単位だったりするので負荷が読みにくい 쏂쏱쏠쎷쏯썗쎂썻썛썽

30.

-Barbeque も kuroko2 と同じように  hako oneshot でジョブを実行(OSS 化済み) -Scale-out は
hakoの特性を使ってやっている - ワーカー単位ではなくジョブ単位で必要な時に必要な分だけオートスケールできる 쏂쏱쏠쎷쏯썗쎂썻썛썽

31.

*NNVUBCMF *OGSBTUSVDUVSF

32.

-言葉がバズってから結構たった -Docker 化により開発者も半ば強制的に意識するようになり、hako で加速 -コンテナ化によりポータビリティが上がりそれを有効活用したシステム構成に出来るようになった *NNVUBCMF *OGSBTUSVDUVSF

33.

-まだ Docker 化出来てない＞＜ -が、もちろん Immutable な構成にはなっている -のでインフラ周りではちょっと面白いことやっているよ〜 썾ɺDPPLQBEຊମ

34.

)5514Խ

35.

-Web の現状を鑑みるとHTTPS 化しない理由がない -新しい技術は HTTPS を要求するものが増えている (HTTP/2 やService worker 等)
-さらなる挑戦のためにも HTTPS 化が必要だった )5514Խ

36.

"NB[PO3FETIJGU쎏쎅 ׬શҠߦ

37.

-去年発表のあった DWH の件 -今までサードパーティの DWH サービスを併用していたが完全に Redshift へ移行した
-データが一箇所に集まった（アクセスログも！） "NB[PO3FETIJGU쎏쎅 ׬શҠߦ

38.

-つまりアクセスログとアプリケーションのデータを join 出来る -例えば神奈川県に住んでいる 20代女性が昨日一番見ていたレシピのタイトルとかが簡単に取れる શ썽쎅쏑썗쏉썣ू쎕쎢 썿썛썝썪썿

39.

-ディレクターも活用 -AB テストなどでもユーザーセグメント作ったり -もちろんプライバシーへの配慮なども取り組んでいる શ썽쎅쏑썗쏉썣ू쎕쎢 썿썛썝썪썿

40.

쎕썿쎘

41.

-この一年もドンドン進歩していった -もちろん今年も更に加速していきます！！ 쎕썿쎘

42.

We are hiring!

Cookpad awakens

Cookpad awakens

Want more?

Transcript