読者です 読者をやめる 読者になる 読者になる

Yet Another Talk on Microservices #microsvc

イベントページ

connpass.com

Microserviceの話

  • 難しいのはどの帽子を被るべきか
  • アーキテクチャはサービスによって変わっていく
    • 最初から100万人に向けて作るとかは良くない
    • 100万人のユーザーを作る前にチームは解散するでしょう
  • 今日の正解は明日の不正解
    • プロダクトに求められる要件は変わっていく
    • 最初から設定を固定化する必要が無い
  • そういう意味でこの本は本当に素晴らしい

キラキラネーム現象

  • マイクロサービスを行う中でのあるある
    • 好きに名前をつけることができる
    • プロジェクトに愛着もつく
  • 今まで務めている会社だとアメリカだとコードネームドリブンになる
  • 日本の会社は真面目な名前を付けがち

会話例

  • 新人に説明するときに、ドキュメントを読んで勉強してコードを書いて開発すると、質問が生じる
  • 先輩に質問すると、「それはFujisanからくるんだよ」「これはRokkousanにPostするんだよ」「それはTsukiが見てくれるんだよ」

Fastlyの場合

  • スキー好きなので、一つ一つの山の名前がついたりする

モニタリング

  • 全てのサービスはいつフェールしてもおかしくないので、フェールしても大丈夫なようにする

Fastlyでは

  • DATADOGを使ってる
  • NewRelicを使ってもいる

開発環境

  • 人数が増えれば増えるほど、何かが壊れたりする
  • かつ柔軟であるようにしなければいけない
  • どこにいても開発ができるようにしなければならない

皆さんの日常ってどんな感じ

  • 網羅的に全てのパーツに手をいれることはあるか?
  • ある瞬間の興味の対象が限られている
  • ただし、サービス間の依存関係があったりする
  • トラブルシュートをするのはバカらしい

Fastly

  • VM上にLXCsを載せる
  • 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のリージョンを落とした上でサービスがへっちゃらであることを証明する

自転車置き場

  • パーキンソンの凡俗法則
  • 例えばデータフォーマット
  • チームによって考え方が違ったりする
  • JSON:APIで解決
    • APIのRESPONCEのスタンダード

Polyglot Environment

  • polyglot
    • 複数の言語を使っている
  • Fastlyは色んな言語を使っている

Fastlyの歴史

  • 既存のCDNに不満があって、自分で作るように
  • アメリカで上手く行ったのでイギリスへ
  • C言語Perlが得意言語
  • Fastlyの黎明期はC言語Perl
  • 様々なサービスを作ったが、それらを同じ言語で行うのは効率が良くないので、それぞれのサービスで分割して様々な言語に

適切な言語

  • マイクロサービスの心理として、適切な言語とテクノロジーを活用することが大事
  • 必然的にマイクロサービスになった

柔軟なデプロイメント

  • ロールバックによって自分のコードが本番から一時的に消える(ロールバックに巻き添えを食らう)ことがあるはず
  • モノリシックなアプリケーションの一番のデメリット
  • システム全体としては迷惑をかけないのでカオスにならない
  • Fastlyは各チームでデプロイしている
  • 最初はほとんどchefでやっていた

コンウェイの法則

  • Fastlyは多い
  • その中で分割する

まとめ