マイクロサービスのデプロイをどう迅速にするかの解説:マイクロサービスアーキテクチャ感想(3)

個人開発したアプリの宣伝
目的地が設定できる手帳のような使い心地のTODOアプリを公開しています。
Todo with Location

Todo with Location

  • Yoshiko Ichikawa
  • Productivity
  • Free

第6章 デプロイ

デプロイについての章。

  1. CIについて
  2. デプロイ先のアーキテクチャ
  3. environmentについて

が解説されている。

テストがあってこそのCI

ビルドが期待通りに振る舞っているかは、テストがあってこそ。テストがないCIはCIではないと本書では警鐘を鳴らしている。

適切に運用しないとCIを導入しても意味がないよ。という話しでした。

CIの分割について

マイクロサービスを検討する一つに迅速なデプロイってのも材料の一つだと思うけど、その一歩手前、じゃあビルドはどうするの?って話し。

ある一つのサービスのチェックインに対して、すべてのサービスのビルドを始めるようなことになるとビルドタスクが重くのしかかるよね。

そういったビルドの分割について、ソースコードリポジトリの設計からどう戦略を立てていくか?という解説。

まあ、この辺りはみんなサービスごとにリモートリポジトリ分けてるんじゃないのかなあ。とか思いながら読んでいた。

デプロイ先のアーキテクチャについて

これは当然のことだけどアプリケーションにはそれぞれの技術スタックがあるので、デプロイ先となるホストのプロヴィジョニングも自動化しましょうね。という話し。

Infrastructure as Code だったりIaasのイメージだったり。

あとは物理ノード - OS - 仮想ホスト、またはコンテナ内に複数のサービスを乗せるか否かの著者の見解。著者はホスト内に1つがいいんじゃないと述べていて、僕もその意見に賛成だ。

environmentについて

当然、テスト環境と本番環境では設定値や稼働環境が異なるもので、例えば本番でロードバランサ配下で稼働するサービスがあったとして、サーバ側セッションを各サービスで共有してないから、急にログアウトしちゃった(>_<)みたいな失敗談。

テスト環境も本番環境に近づけないといけないけど、どこまで近づけるかは見極めよう。という話し。

あとはフレームワークなんかではよくある、environment.yamlなんかに

production: ...
development: ...
test: ...

のおさらい的なお話しでした。

この章の感想

デプロイの自動化と「どう迅速に行うか」の解説でした。

依存度が高いサービスについて、どう順序よく同時にデプロイするか。やサービスを止めずに行うか。なんて事には触れてないのであしからず。