国産のマイクロサービス本！ の続きだぞい
同書の読書記録と感想、後編です。
- 国産のマイクロサービス本！ の続きだぞい
- ■第2部 マイクロサービスを支えるクラウドネイティブテクノロジー
- 第5章 コンテナ＆Kubernetes＆サーバーレス
- 第6章 サービスメッシュ
- 第7章 マイクロサービスの開発と運用
- 第8章 クラウドデプロイメントモデルの動向
- まとめ：マイクロサービス関連の最新状況が俯瞰できる本
■第2部 マイクロサービスを支えるクラウドネイティブテクノロジー
第1部では作り方の観点から述べてきましたが、第2部ではマイクロサービス周辺のIT技術を紹介していきます。
第5章 コンテナ＆Kubernetes＆サーバーレス
5.1 コンテナ
- 「コードとそのすべての依存関係をパッケージ化したソフトウェアの標準的な単位で、アプリケーションがあるコンピューティング環境から別のコンピューティング環境へも迅速かつ確実に実行されうようにする」もの。
- 環境の違いを吸収するのでポータビリティが高く、サーバーリソースを有効に使え、構成ファイルでデプロイ作業を担当できる。
- コンテナはOSレベルの仮想化なので、
DockerコンテナはホストOSから見ると１つの特別なプロセスである。Linux Namespaces,cgroupsのようなLinux系の機能が活用されている。 - Linuxのカーネル技術でも1970年代から様々な新機能が追加され、進化があり、その結果として2013年にDockerがリリースされて人気に。
- Dockerイメージの中はコンテナレイヤーがあり、イメージレイヤーが複数あり...と層の構造になっており、OSレイヤーを再利用して効率化を図ったり工夫している。
5.2 Kubernetes
- Dockerは1台のマシンで複数のコンテナを効率的に管理する仕組み。マイクロサービスの規模が大きくなってくると複数のマシンでよりたくさんのコンテナを管理することになる。こうしたケースで、コンテナエンジンのさらに上のレイヤーでコンテナを俯瞰的に管理する仕組みが、「コンテナオーケストレーション」。
- 垂直でなく水平方向に安価なマシンを並べて広げるスケールアウトの考え方を実現する。
- 可用性、冗長性を持ったコンテナの作成とデプロイ。負荷に応じたスケールアウト、スケールダウン、ロードバランシング。ホストやコンテナのヘルスチェック。これらの役割を担当するのがオーケストレーター。
- 事実上
Kubernetesがデファクト。アイコンにあるようにギリシャ語の「舵取り」「パイロット」の意味。 - k8sの中にはKubernetesクラスターがあり、全体の機能を担当するコントロールプレーンコンポーネントが１つ。ノードコンポーネントがN個あり、この中のPodにコンテナが載っていく。
- クライアントは
kubectlで、クラスターとは全てKubernetes APIを通じて会話。
DockerとKubernetesの節は第一部と別の方が書いているのか、かなりディープです！
5.3 サーバーレス
- サーバーがないのではなく、サーバー管理不要でアプリケーションを構築して実行する概念の総称。
- 従来の
クライアント<->APサーバー<->DBサーバーの3層構造のWebアプリとアーキテクチャ的には以下が変わる。 - コードのライフサイクルは短く、単一のHTTPリクエスト/レスポンスまでに近い。これごとに課金なのでお安い。
- これまでのコア機能を一部置き換えるサードパーティサービスを
BaaS: Backend as a Service、あるいはモバイル特化だとMobileをつけてMBaaSと呼ぶ。Google FirebaseやAuth0など。 - イベントドリブンな関数ベースのサービスを
FaaS: Function as a Serviceと呼ぶ。AWS Lambda, Azure Functions, Google Cloud Functions。 - 狭義では
FaaSのみをサーバーレスと呼ぶときもある。ふつうはBaaSとFaaS合わせてサーバーレスプラットフォームとなる。
ある程度知っているとこのへんは復習として理解しやすいです。絵があるので分かりやすいです。
- 非同期で独立した処理、要求頻度の低い処理、スケーリングのばらつきが多い処理、ステートレスで短い処理、迅速に修正が必要な処理などのワークロードで有効。
- マルチメディアの処理：
Amazon S3に画像アップロード時に関数で変換など。 - DB変更のトリガー：データ変更のタイミングで別サービスを呼んだり非同期のロジック処理など。
- IoTセンサー：IoTデバイスからの大量のメッセージを効率的に処理など。
- 大規模ストリーム処理：多数のメッセージを処理するには高いパフォーマンスや柔軟性が必要、これもサーバーレス向け。
- バッチやスケジュールされたタスク：1日1回数分の大きい処理など。使用している時だけコスト発生。
- REST API、Webアプリケーション：個々のクライアント画面からRESTでデータを呼び出す際にも有効。
- Continuous Integretion(CI)：コミットなどのタイミングで起動する処理もサーバーレスにすると、動く時だけコスト発生でお得。
メリットは以下が説明されています。
- サーバー管理不要でコスト削減。
- BaaSではアプリケーションのコンポーネント自体がよくある機能でコモディティ化できるので、使い回せる。
- FaaSは実際に処理した時間だけ課金なので明らかにお得。
- 運用保守も楽になり、インフラのセキュリティ管理も不要。
制約は以下が説明されています。
- 基本ステートレスなので、ステート管理が必要な場合はインメモリDBなどが必要。ストートレスに再設計する手間もあり。
- あるBaaSへのプロトコルがRESTだったら、レイテンシーが大きくてもプロトコルを変えたりはできない。
DynamoDB Localなどもあるが、基本的にローカル開発環境でのテストが難しい。- コンテナ起動直後はコールドスタートで時間が掛かったりする時も。リアルタイム処理が求められるユースケースで問題に。
- FaaSはコンテナ上で実行されるので、ツールや実行環境は限定的
- サーバーレスは業界標準がまだ進んでいないのででベンダーロックインされる。
5.4 デプロイメント技術の比較とまとめ
コンテナオーケストレーション→PaaS(Herokuなど)→サーバーレスへと進むごとに、ビジネスロジックによりフォーカス、インフラの手間が減っていく。- コンテナオーケストレーションはインフラを自分で管理、ベンダーロックインを避けられる、ポータビリティあり。逆に自分たちでインフラ運用が必要。
- PaaSはOSやコンテナの管理不要、デプロイが迅速。逆にベンダーロックインはされてしまい、細かいインフラ制御もできない。
- サーバーレスはビジネスロジックそのものに注力、実行時間だけ課金。逆にまだプラットフォームやコミュニティが成熟していない、既存アプリの移行はハードルが高いという課題あり。
デプロイの観点でコンテナ、PaaS、サーバーレスを捉え直した話は勉強になりました。
第6章 サービスメッシュ
6.1 サービスメッシュの必要性
- たくさんのマイクロサービス群から構成されるので、
Service Discoveryでサービスのネットワーク上の位置を探したり、リクエストのトラフィックを制御したり、外からわかるよう可観測性(Observability)を持たせたり、障害が起こったらそのサービスだけ分離したり、セキュリティの配慮が必要。 - これらからサービスメッシュという考え方が取り入れられてきた。
6.2 サービスメッシュとは
- 隣り合うサービス間が網の目、メッシュ上に繋がった状態で、サービス間通信を管理する仕組みが「サービスメッシュ」。
- 各サービスすべてに付随する軽量なプロキシを設ける。これが「データプレーン」。
- それとは別に全体で１つの「コントロールプレーン」がサービスメッシュ全体を管理。
- 各サービス本体はどんな技術で開発されていても、付随したデータプレーンの中でよろしくやってくれるので気にする必要がない。サイドカーパターンというデザインパターン。
6.3 サービスメッシュでできるようになること
- コントロールプレーンがIPの対応表を持ち、
Service Discoveryを実現。負荷分散も行う。 - トラフィックコントロールが行える。バージョン1と2のサービスに%でトラフィックを分割したり、条件に応じてトラフィックしたり、ステータスコード500を返す障害を注入して通信障害テストに使えたり。
- あるサービスにエラーやタイムアウトが多発したら、そのサービスへのアクセスは即座にエラーを返すように変更する「サーキットブレーカー」の機能。
- イベント/ログ/メトリクス/トレースなど定期的に生成されるデータを「テレメトリーデータ」と言うが、これらを収集、分散トレーシングする機能。サービスをまたがるリクエストを追える。
- 証明書の配布など、セキュリティ機能。
6.4 サービスメッシュのソフトウェア例
Istio: Google、IBM、Lyftの3社製。2020/3にv1.5.Linkerd: 2017/4にv1.0.0。k8sだけでなくAWS上でも動く。2018/9のv2.0系はすべてGo,Rust言語で置き換え。Consul: HashiCorp開発。2018年にv1.2。- 2019年から、Service Mesh Interface(SMI)というサービスメッシュの標準化が開始。違うソフトウェアに乗り換えても大丈夫な姿を目指している。
サービスメッシュというとIstioが有望株とだいたい本に書いてあるのですが、この３つが有名のようです。
istio.io linkerd.io www.consul.io
第7章 マイクロサービスの開発と運用
7.1 マイクロサービスの開発と運用
大規模で複雑な分散システムには、全体像の把握が難しい、機能追加のリリースに全体を待たなければならない、ビルドや統合に時間がかかる、システム全体の物件がでかいなどの課題あり。ということでマイクロサービスの優位点は以下を挙げています。
- サービスごとなのでリリースがしやすい。
- ドメイン駆動設計を使うとサービスの境界や依存関係を明確に分けられる。
- コンパクトなサービスになれば少人数で開発できる。
- それぞれのサービスで自由に開発、言語などテクノロジスタックも最適な選択ができる。
- サーキットブレイカーなどがあれば障害の影響を最小化。
- 自分のサービスで問題発生時も切り戻せば他のサービスへの影響が少ない。
- 精神的にも安心して自由にデプロイできる。
注意点は以下を挙げています。
- 動的パーツが増えるのでシステム全体の把握は難しい。
- サービス間通信の実装が必要。
- 他のサービスに依存するようなサービスではこれまでと異なるアプローチがいる。依存を定義してリファクタするのが難しいなど。
7.2 マイクロサービスの開発と運用に必要なプラクティス
- 最初は2009年に言及のあった
DevOpsがよく話題にされる。ツールや手法が話題にされがちだが、組織やチームのカルチャーの熟成が必要。 - CI/CDパイプラインは海外ではCIがなくなって
CD Pipelineと呼ばれることもあるとのこと。 - CI/CDの派生として、Gitを中心に据えて各種オペレーションを自動化する手法を
GitOpsと呼ぶ。 IaC: Infrastructure as Codeで、インフラもコードとして管理しリポジトリで管理。Immutable Infrastructureで、一度構築したインフラは変更しない。変更時はそれらの変更を適用した新しいインフラをデプロイする。
7.3 マイクロサービス開発に必要な環境
- 個人でコンテナの実行環境が欲しい場合は
Docker Desktopを使うとよい。 - IDEやエディターはいつも通り。
VSCodeのリモートデバッグでコンテナに繋いだりライブシェア機能を使うのが役に立つ。 - チーム開発では各種コミュニケーションツール、タスク管理などの開発管理ツール、ソースコードリポジトリ。デプロイ環境は開発/ステージング/本番の3つが多い。
- ソースコード管理では各サービスのソースコードのほかに、コンテナ定義ファイル、GitHubなどのパイプラインやワークフローの定義ファイル、インフラやミドルウェアの定義ファイル(AWS CFnやAnsible)、構築スクリプトなどが増える。
7.4 リリースマネージメント
- ビルドからリリースまでのパイプラインで人が介入するのはレビューや承認程度にとどめるのがよい。
- パイプラインツールとしてはNetflix製の
Spinmaker、Flux2/Flaggerが有名。
7.5 マイクロサービスの監視と運用
- Googleのエンジニアが大規模システムの成功プラクティスをまとめた
SRE: Site Reliability Engineeringのプラクティスが有効。組織の孤立を減らす、失敗の許容、段階的な変更の実装、ツールと自動化の活用、すべてを計測/観測可能にする の5つの基本原則。 - リクエストに対するレイテンシ、トラフィック、エラー、サチュレーション(パフォーマンス限界までの到達度)の４つが、SREでは「ゴールデンシグナル」と呼ばれる監視の勘所。
- k8sでは様々にメトリクス収集方法がある。ワーカーノードには保存せず別の場所に保存する。
- 収集や監視のツールでは、
Elastic Search + LogStash(あるいはFluentd) + Kibanaが有名。各パブリッククラウドにはそれぞれ用意されている。 - 収集では
Sysdig、イベント監視ソリューションとしてPrometheusというツールがある。
この章はSRE領域も多い話でした。GitOpsという用語もあるのですね。
第8章 クラウドデプロイメントモデルの動向
最後はマイクロサービス周辺のクラウドプラットフォームの動向の章。
8.1 クラウドデプロイメントモデル
- パブリッククラウド、プライベートクラウドの他に、特定の利用者のグループがクラウドを共有する「コミュニティクラウド」というモデルもある。
- またデータセンターに実体が置いてある一般のパブリッククラウドのサービスでも、利用できるのが単一の利用者なら、そのクラウドサービスはプライベートクラウド扱いになる。
8.2 ハイブリッドクラウド
- パブリック/プライベート、複数のクラウドデプロイメントモデルを組み合わせて使うのが、ハイブリッドクラウド。
- SoE-SoR連携型、業務ごとに使い分け型、災害対策型、プライベート上の業務処理がパブリックなSaaSを呼ぶSaaS連携型。ピーク時にパブリッククラウドで補うピーク対応型、データが行き来できる可搬型、事前のポリシーで使い分けるブローカー型がある。
8.3 マルチクラウド
- 複数のパブリッククラウドサービスを併用するやり方。近年注目されている。
- ベンダー各社の良いとこどりができる、障害発生時にリスク分散、ベンダーロックインを回避できるのがメリット。
- 開発運用手順がそれぞれ違ったら一貫性がない、セキュリティリスクが増大する、クラウド間のシステムやデータの移行が難しい場合があるのがデメリット。
8.4 コンテナとハイブリッド／マルチクラウド
- オープンソースである
Kubernetesを中心にアプリケーション実行基盤に置くことで、クラウドプラットフォームの違いを抽象化して相互接続性を確保できる。 - クラウドベンダーごとの様々な違いをk8s利用時に吸収する必要あり。
8.5 分散クラウド
- パブリッククラウドサービスを様々な物理的な場所に分散させ、パブリッククラウドプロバイダーがサービスのオペレーション、ガバナンス、進化に対する責任を引き続き負うこと。
- パブリッククラウドを利用しつつ、サブセットを自社内のデータセンターに配信、機密性の高いデータはこちらに置いたり。
- 企業の定める環境でパブリッククラウドの長所を得られる。
8.6 エッジコンピューティング
- IoTデバイスやエッジサーバーなど、データソースの近くでエンタープライズアプリケーションを実行するやり方。
- AIによる新たなビジネス課題の解決、システムの分析能力の向上、ソースに近いのでデータ量削減でセキュリティ向上、5Gネットワークの活用が見込まれる。
各種デバイス→工場や店など、その近くにエッジサーバー→5Gネットワークで通信→ハイブリッド/マルチクラウドという繋がり。- クラウド上で全てのデータを処理したり分析するより待ち時間が短くて済む。
8.7 まとめ
かつては巨大で高価なホストコンピュータ(集中)→
1990年代にクライアント-サーバー型(分散)→
2000年代からWebアプリケーションが一般的になる(集中へ折り返し開始)→
2010年代中心にクラウドコンピューティング(さらに集中)...
という風に、歴史の中でシステム構成が集中と分散を繰り返しているという説は時折語られます。また分散の時代が未来に来ようとしているのですね。
Kubernetesを使うだけでそんな簡単にマルチクラウド行けるもんかな？ という気もしましたが、オープンソースの中立的な立ち位置にいるKubernetesが注目されている理由にはこのへんも関係しているわけですね。
まとめ：マイクロサービス関連の最新状況が俯瞰できる本
2021年7月発売なので国内では最新のマイクロサービス本となります。著者・監修者の方々はIBM、マイクロソフト、元AWSJの方々。ということで翻訳本にありがちな不自然な日本語もなく、日本人の書いた本で読みやすい日本語でさらっと読むことができました。
それぞれの事柄はそんなに詳しくはないのですが、マイクロサービス周りの事柄はだいぶ網羅されており、一式を把握することができます。図の中の人間の絵がいつも使い回しなのが若干気になりましたが(笑)図表も豊富です。
もとから対象読者層が違うのでしょうが、前半のマイクロサービスアーキテクチャやパターン周りは概念は書いてあるのですが、より実装レベルの作り方の話や実際の技術などなどは載っていないんですね。まあこのへんは『マイクロサービスパターン』などほかの本やWeb資料を参照ということでしょうか。
おまけ：日本語で読めるマイクロサービスパターンの商業本
2016年に一番最初に和訳されたオライリー本が『マイクロサービスアーキテクチャ』。
2017年9月にはオライリーから『プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化』という本も出ました。
2018年1月に『マイクロサービス入門 アーキテクチャと実装』という初心者向けの本も実は出ていたようですがあまり良い内容ではないようです。
2020年3月に翻訳が出たのが『マイクロサービス パターン［実践的システムデザインのためのコード解説］』。500ページに及ぶかなり分厚い本ですがこれを読むとだいぶ解像度が上がります。
読むのに骨が折れましたが、当ブログでも３回に分けて読書記録を残しています。
ネットでもあまり話題にならず書評も見当たらず詳細が謎ですが、2020年11月に『マイクロサービス インアクション』という本も翻訳されているのですね。Amazon経由だと【Amazon.co.jp限定】と書名についていてなんか怪しい...
翻訳された方のQiitaの記事がありました。
「マイクロサービス イン アクション」翻訳しました。 - Qiita
2020年12月のオライリー本『モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド』。こちらもエンジニア系のブログであちこちに書評が出ています。
2021年4月には日経クロステックから『開発テクニックの新潮流 マイクロサービス/コンテナ大全』という本も出ました。日経の連載のまとめ本なので、薄めに概要をなぞる感じでしょうか。
