イベントページ
Microserviceの話
- 難しいのはどの帽子を被るべきか
- アーキテクチャはサービスによって変わっていく
- 最初から100万人に向けて作るとかは良くない
- 100万人のユーザーを作る前にチームは解散するでしょう
- 今日の正解は明日の不正解
- プロダクトに求められる要件は変わっていく
- 最初から設定を固定化する必要が無い
- そういう意味でこの本は本当に素晴らしい
キラキラネーム現象
- マイクロサービスを行う中でのあるある
- 好きに名前をつけることができる
- プロジェクトに愛着もつく
- 今まで務めている会社だとアメリカだとコードネームドリブンになる
- 日本の会社は真面目な名前を付けがち
会話例
- 新人に説明するときに、ドキュメントを読んで勉強してコードを書いて開発すると、質問が生じる
- 先輩に質問すると、「それはFujisanからくるんだよ」「これはRokkousanにPostするんだよ」「それはTsukiが見てくれるんだよ」
Fastlyの場合
- スキー好きなので、一つ一つの山の名前がついたりする
モニタリング
- 全てのサービスはいつフェールしてもおかしくないので、フェールしても大丈夫なようにする
Fastlyでは
- DATADOGを使ってる
- NewRelicを使ってもいる
開発環境
- 人数が増えれば増えるほど、何かが壊れたりする
- かつ柔軟であるようにしなければいけない
- どこにいても開発ができるようにしなければならない
皆さんの日常ってどんな感じ
- 網羅的に全てのパーツに手をいれることはあるか？
- ある瞬間の興味の対象が限られている
- ただし、サービス間の依存関係があったりする
- トラブルシュートをするのはバカらしい
Fastly
- VM上にLXCｓを載せる
- PC内でほぼ本番内の環境ができる
- 開発環境はセットなので、誰かがどこかを変更している
- 更新したらテストが動かなくなったり
- 外部要因によって泣かされる
- 開発環境をメンテしている専門のチームがいる
マイクロサービスとテスト
- correctnessをテストする
- 外部サービスとの連携をテストするのはトリッキーになる
- Rubyの場合、Mochaがあるが、まだ足りない
- リクエストとレスポンスを取得する仕組みとか
- カセットのデータのメンテが大変
- マイクロサービスは気を使うことが増える
- earlyのサービスはそこらへんも行う必要はない
Testing Resiliency
- そのマイクロサービスはどこで動いている？
- 開発者にとってはどうでも良い
- モノリシックな場合は別に良い
- Test the extra mile
- よくあるのがネットワーク障害とか、外部要因とのバグ
Shopify
- toxiproxy
- ネットワーク環境を監視できるgem
- これでResiliencyをテストできる
- 色々な通信対象をテストできる
- Building and Testing Resiliency Ruby on Rails
CHAOS MONKEY
- 本番環境でわざと落とすプログラム
- CHAOS ENGINEERING
- AWSのリージョンを落とした上でサービスがへっちゃらであることを証明する
自転車置き場
Polyglot Environment
- polyglot
- 複数の言語を使っている
- Fastlyは色んな言語を使っている
Fastlyの歴史
- 既存のCDNに不満があって、自分で作るように
- アメリカで上手く行ったのでイギリスへ
- C言語とPerlが得意言語
- Fastlyの黎明期はC言語とPerl
- 様々なサービスを作ったが、それらを同じ言語で行うのは効率が良くないので、それぞれのサービスで分割して様々な言語に
適切な言語
柔軟なデプロイメント
- ロールバックによって自分のコードが本番から一時的に消える（ロールバックに巻き添えを食らう）ことがあるはず
- モノリシックなアプリケーションの一番のデメリット
- システム全体としては迷惑をかけないのでカオスにならない
- Fastlyは各チームでデプロイしている
- 最初はほとんどchefでやっていた
コンウェイの法則
- Fastlyは多い
- その中で分割する
