https://techconf.cookpad.com/2017/
$PPLQBEBXBLFOTঙ࢘Յ৫∠
View Slide
ঙ࢘Յ৫yoshioriٕज़෦ਓࣄ෦∠
ਓࣄ෦バックオフィスでも技術が分かる人がいることが大事 エンジニアの採用にも、もちろん大事エンジニア以外に人権が無いのではない逆に変に神聖視されないためにも大事
ٕज़෦
࠷ॳ쎂
まだまだいっぱい
쎿썗쏝쏃쎅ׂ썿࿈ܞ
쎿썗쏝쏃쎅ׂ썿࿈ܞmicroservices化によってサービス間の連携が大事になった。サービス間の境界に対して Pact と Expeditor というのを使っている-障害を制御する Expeditor-障害を予防する Pact
&YQFEJUPS-サーキットブレイカー-並列リクエスト-リトライ制御cookpad/expeditor
1BDU-サービス間の連携部分のテスト-簡単に言うと Service-A が返す JSON と Service-B が期待する JSON のテスト-Consumer-Driven Contract testing (CDC testing)- 詳しくは http://techlife.cookpad.com/entry/2016/06/28/164247
[email protected]@GPSNBUUFS-規模が大きいアプリケーションでは、pactverification が失敗した時に出力が多く見づらい-JUnit のフォーマットにすることで CI などでも見やすいようにするプラグインtaiki45/pact_junit_formatter
[email protected]-Remote Facade のテストでのみ Pact を使い、その他の層では Remote Facade をモックするように-Pact の expectation をレスポンスとして流用できる-ちゃんと設定したものが両方で呼ばれていることも確認できるyoshiori/pact_expectations
1IBLDIJ-iOS からの API 呼び出しも-Pact の expectation を楽に記述できる-Swift 製-XCTest から利用cookpad/Phakchi
쎿썗쏝쏃쎅쏧썗쏉쏝쏴쏐쎭分割したサービスは全て Docker 化されているDocker を更に有効的に使うために hako を作った
IBLP
IBLP-Docker のデプロイツール- 今のところ ECS に対応- 定義は YAML で記述 （Ruby DSL とかは無い）eagletmt/hako
-一昨年から新規はすべて Docker、既存のものもどんどん Docker 化は結構進んでいた。-が、どうしてもインフラ作業などは発生する。- アプリケーションサーバ以外の機能 （RDS、Route53、ELB などなどの設定）- 環境変数の追加など （DB 情報や APIのキーなどの秘匿値）IBLP
IBLP-定義は YAML で記述-ソフトウェアと同様に開発者が管理ができ、git&github 等で管理、レビューが出来る-cookpad では hako_apps というリポジトリで集中管理してる
IBLP-秘匿値を含む環境変数の扱い- etcd をバックエンドにした etcvault を使用- 現在 hashicorp/vault に移行中sorah/etcvault
-デプロイに処理を差し込む- Route53 の自動設定やデプロイするリビジョンを jenkins から取得等-詳しくは下記- https://speakerdeck.com/eagletmt/ecs-woli-yong-sitadepuroihuan-jing- http://techlife.cookpad.com/entry/2016/09/09/235007IBLP
-hako deploy- デプロイを実行するコマンド- クックパッドではコマンド実行に Rundeck を使用-hako oneshot- バッチ系IBLP
LVSPLP
-ジョブ管理システム- 各チームのジョブスケジュールを 可視化する機能などもあり-Ruby で書かれてる-Web UI がある-細かい話は http://techlife.cookpad.com/entry/2015/12/07/195732LVSPLPcookpad/kuroko2
-ジョブ管理を最初は cron で雑に管理していて破綻する- どのサーバでやるか- リソース使い切って分散したくなったり- バッチ用のサーバ立てたり쏂쏱쏠쎂썻썛썽
-DB への接続やドメイン特有の処理など Web アプリと共有したいものは多い-普通にやると job 実行は web アプリを内包しなきゃいけなくなる- デプロイが別になったり大変- プロビジョニング自動化してても大変……- ワーカーは最強の権限をもったサーバになりがち쏂쏱쏠쎂썻썛썽
-hako oneshot- ECS task なので IAM role を設定できる- 権限管理や秘匿値の管理がコンテナ単位になって適切にサービス毎に権限が管理できる- デプロイを気にする必要ない （Dokcer イメージを hako で実行するため）쏂쏱쏠쎂썻썛썽
#BSCFRVF
-ジョブキューシステム-Ruby で書かれてる-kuroko2 と同じような Web UI-細かい話は https://speakerdeck.com/k0kubun/scalable-job-queue-system-built-with-docker#BSCFRVFcookpad/barbeque
-Rails だと Resque や Sidekiq 使うことが多い-さらにキューの管理が複雑に-起動がユーザリクエスト単位だったりするので負荷が読みにくい쏂쏱쏠쎷쏯썗쎂썻썛썽
-Barbeque も kuroko2 と同じように hako oneshot でジョブを実行(OSS 化済み)-Scale-out は hakoの特性を使ってやっている- ワーカー単位ではなくジョブ単位で必要な時に必要な分だけオートスケールできる쏂쏱쏠쎷쏯썗쎂썻썛썽
*NNVUBCMF*OGSBTUSVDUVSF
-言葉がバズってから結構たった-Docker 化により開発者も半ば強制的に意識するようになり、hako で加速-コンテナ化によりポータビリティが上がりそれを有効活用したシステム構成に出来るようになった*NNVUBCMF*OGSBTUSVDUVSF
-まだ Docker 化出来てない＞＜-が、もちろん Immutable な構成にはなっている-のでインフラ周りではちょっと面白いことやっているよ〜썾ɺDPPLQBEຊମ
)5514Խ
-Web の現状を鑑みるとHTTPS 化しない理由がない-新しい技術は HTTPS を要求するものが増えている(HTTP/2 やService worker 等)-さらなる挑戦のためにも HTTPS 化が必要だった)5514Խ
"NB[PO3FETIJGU쎏쎅શҠߦ
-去年発表のあった DWH の件-今まで サードパーティの DWH サービスを併用していたが完全に Redshift へ移行した-データが一箇所に集まった（アクセスログも！）"NB[PO3FETIJGU쎏쎅શҠߦ
-つまりアクセスログとアプリケーションのデータを join 出来る-例えば 神奈川県に住んでいる 20代女性が昨日一番見ていたレシピのタイトルとかが簡単に取れるશ썽쎅쏑썗쏉썣ू쎕쎢썿썛썝썪썿
-ディレクターも活用-AB テストなどでもユーザーセグメント作ったり-もちろんプライバシーへの配慮なども取り組んでいるશ썽쎅쏑썗쏉썣ू쎕쎢썿썛썝썪썿
쎕썿쎘
-この一年もドンドン進歩していった-もちろん今年も更に加速していきます！！쎕썿쎘
We are hiring!
yoshiori
makamaka
bun913
drumath2237
line_developers_tw
nenonaninu
wadayusuke
daina0321
megabitsenmzq
takashiinui
ybrliiu
gen519
carta_engineering
phodgson
sugarenia
paulrobertlloyd
garrettdimon
mraible
eileencodes
jnunemaker
jensimmons
davidbonilla
3n
chriscoyier
maltzj