運営者情報

運営してるひと: @sters9

       

妻と猫と横浜あたりに住んでいる。最近は Go や Kubernetes や GCP をしています。 PHP や JavaScript もすこし。

プライバシーポリシー

tools.gomiba.co

アーカイブ

2021/06 (5) 2021/05 (10) 2021/04 (1) 2021/03 (8) 2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)

Microservice architecture patternsを読む - Microservice Architecture

  • トップページ: A pattern language for microservices

  • 読んだもの: Microservice Architecture pattern

  • これはアプリケーションアーキテクチャのひとつ

  • ひとことでいうと、アプリケーションを複数のサービスで疎結合に分離して扱う

    • 別のサービスの変更に影響を受けたり与えたりをすることなく開発やデプロイが可能な状態
    • データベースも分離され、各サービスは各サービスごとのデータベースを持つ
    • コミュニケーションは決まったフォーマットを使う、HTTPとかRESTとかAMQPとか
      • 最近ならgRPC? Android/iOS、Webフロントエンド等があるならJSON+Protobuf?がはやり?
  • この記事ではECサイトを例に上げている

    • アプリ用のAPI Gateway
    • ショップとしてのフロントエンド
    • アカウント管理とそのデータベース
    • 在庫管理とそのデータベース
    • 配送管理とそのデータベース
    • 個々のサービスそれぞれを開発、運用していく
  • Microserviceのメリットは大きなアプリケーションでも個々の要素を小さく保つことでできるところ

    • チームが1つ(か複数)のサービスに責任を持ってそれに集中できる
    • 疎結合なので何かのサービスがダウンしても他のサービスは影響を受けない
      • アプリケーション全体として、一部の機能が動かないけどそうではないものは提供ができる
    • 新しい機能(新しいサービス)を作るとき、利用する技術を選べる
      • サービス間のコミュニケーション方法について取り決めがあれば、中身は何でもいいはず
        • 例えば、あるサービスはGoで作られているけれど、別のあるサービスはJavaが使われている、みたいなもの
        • データベースも個々のサービスが責任を持つので、どのサービスがどのデータベースを利用しているかは影響しない
  • 逆にデメリットとして、分散システムになる、ということがある

    • データまわり。一貫性とか分散トランザクションとか
      • 記事ではSagaが使える、と書いてある
    • サービスをまたいだテスト、開発をどのようにするか
      • 基本的にはサービス内で完結するのがいいと思うのだけれども、アプリケーションはそうではないので、そこをどう解決するか…
      • 例えば、開発環境だろうとも安定したものをかならず用意する(本番環境と同じように運用する)、で開発環境の安定性を取る、とか
      • 例えば、複数のサービスにまたがる開発は Feature Flag の仕組みをいれて、実装は既にあるんだけど有効にはなっていない、とか
    • 消費リソースの増加(マシンリソース、人的リソース)
      • 💸💸💸💸💸
  • そしてこの記事では多くの問題に取り組む必要があると書いてある

    • いつMicroservice architectureにするか
      • 最初からやっても難しいしMonolithicで作って後から分割するのも難しい
      • いつやるの! ~今でしょ~
      • Monolithicを読んだほうでも書いたけれど、アプリケーションの性質によっていつやるのがいいか、に万能な答えはないとおもう
        • Monolithic だけれども、コード上での実装はそれぞれの役割が疎結合になっていると後からでも比較的分離しやすくてよいのではないだろうか
          • データベースの操作を分離するのは難しいのでソースコードだけ分離されている、みたいなイメージ
          • というか普通にそういう実装を意識したほうがきれいになるとおもう、ちょっと違う気がするけど Clean Architecture 的な
        • 逆にMicroserviceだけれど密結合になってしまっているのであれば、分散システムになっただけのMonolithicで、双方のデメリットが強くでてしまうのではないだろうか
          • 先にでていたECサイトの例に合わせて考えると、たとえばセッション管理の都合などでフロントエンドサービスがアカウント管理サービスと強く紐付いていて、アカウント管理サービスがダウンした場合にフロントエンドサービスもダウンしてしまう
            • インデックスがまったく効かない大きなクエリがアカウント管理サービスのデータベースに実行される(CPUにクリティカルヒットするクエリ)などが起こる可能性は十分にある
            • あるいはアカウント管理は頻繁に参照されるのでキャッシュをしているが、そのキャッシュがフルになってしまう、とか、キャッシュが空っぽになって一斉にクエリが走ってしまう、とか
            • ダウンする可能性はいろいろな理由がありえそう
    • どうやって個々のサービスに分割するか
    • データの一貫性をどう担保するか
    • “クエリ"をどう実装するか
      • これは複数サービスにまたがるデータをどう取得するか、かな…?
  • Related patterns とこの記事でたくさんのパターンが挙げられているけれど、これらはMicroserviceをやる上で遭遇する問題への対処法

    • 対義語?的なものでは Monolithic <-> Microservice になる