Fleetman Microservices in Kubernetes

リチャード：このコースでは､ 開発チームからシステムを渡され､ 彼らがすでに一連のDockerイメージを構築している､ というシナリオを想定しているんだ｡ そして､ 運用エンジニアとしてのあなたの仕事は､ それをクラウドにデプロイすることです｡ さて､ これをご覧になっている方の多くは､ 現実には開発運用エンジニアとして働いている､ あるいは開発運用エンジニアを目指していることでしょう｡ その時に､ 開発と展開の両方に携わることになるわけですね｡ そこで､ DockerHubでビルド済みのイメージのシリーズを用意しました｡ このセクションでは､ Richard Chesterwood リポジトリの下にある com を使用し､ これらを組み立てることがあなたの仕事です｡ そして､ ジグソーパズルのように少しずつ組み立てていく必要があります｡ このシステムには5枚の画像しかありませんが､ これは最も基本的なマイクロサービス・システムを構築したためです｡ しかし､ それでもそれなりに複雑なシステムであることは確かで､ ハローワールドのアプリケーションではありません｡ しかし､ もちろん､ システムのアーキテクチャとその展開方法をある程度理解していただかないと､ これらのイメージの展開を開始することはできません｡ そこでこのビデオでは､ このマイクロサービス・システムの全貌を紹介します｡ これは､ システム内のすべてのDockerイメージがどのように連携しているかを示すハイレベルな図です｡ ここにある1､ 2､ 3､ 4､ 5という箱はそれぞれ､ 先ほどDockerHubで見たDockerイメージに関連するものです｡ これは､ 私が数年前から､ マイクロサービスやそれに類する技術に基づくトレーニングコースを行う際には必ず使っているシステムです｡ その狙いは､ すべての概念を説明するのに十分なほど複雑で､ 圧倒されるほど複雑ではないことです｡ 本当に良い事例になりますね｡ シンプルなカットダウンシステムとして設計されていますが､ このシステムには相応の複雑さがあります｡ 内情が分からなくても､ 展開できるようになるんだ､ と気負わずにいてほしいですね｡ しかし､ このビデオでは､ システムのアーキテクチャを紹介し､ それぞれのパーツがどのようなもので､ どのように組み合わされているのかを説明したいと思うのです｡ このコースで展開するシステムは､ ある種の運送会社で､ 全国を移動する車両を追跡する必要があるシステムです｡ つまり､ 宅配便のトラックが全国を移動するようなものですね｡ 各車両には全地球測位システムが搭載されており､ 定期的に（10秒に1回程度）､ 車両が現在位置を中央サーバーに報告するようになっています｡ そして､ 多くの車両がフィールドに出て､ 常に自分の位置を報告することになります｡ もちろん､ 難しいのは実車がないことです｡ そして､ そのおかげで､ マイクロサービスの1つ目を紹介することができます｡ こちらのこちらは､ ポジションシミュレーターというマイクロサービスです｡ そして､ その名の通り､ このマイクロサービスは､ 全国を移動するそれらの車両をシミュレートするつもりです｡ 非常にシンプルなマイクロサービスです｡ このシステムのコードを理解する必要は本当にありません｡ 私たちの仕事はシステムをクラウドにデプロイするだけですが､ このシステムの深い内部を見ることに興味を持つ方も多いと思います｡ このシステムのコードはすべて私のGitHubリポジトリ「K8s-fleetman」にあります｡ そして､ GitHubでの私のユーザー名はDickChesterwoodです｡ 実際の開発プロジェクトでは､ 各マイクロサービスをそれぞれリポジトリとして管理することが多いのですが､ シンプルにするためと､ 記録時のGitHubには関連リポジトリをまとめる良い方法がないため､ 各マイクロサービス用のフォルダを持つ単一のリポジトリとすることにしました｡ どのサービスも､ K8s for Kubernetes of course dash fleetman dashというフレーズで始まり､ その後にサービス名､ マイクロサービス名､ サブシステム名などが続きます｡ そこで､ ポジションシミュレーターをご紹介します｡ たまたまJavaで実装されており､ Spring Bootを使っています｡ 言ってみれば､ それらの技術に精通しているかどうかは､ 本当に重要なことなのです｡ 私はただ､ このデータがどこから来ているのか､ 本当にお見せしたいだけなのです｡ つまり､ この特定のマイクロサービスでは､ 起動時に一連のファイルを読み込むのです｡ そして､ そのファイルの中には､ 車両をシミュレートするためのテストデータも入っています｡ そして､ 本当に無限ループとして実行され､ 数秒ごとにランダムにファイルから読み込まれるのです｡ これらのファイルが､ SRCフォルダの下､ そしてmainの下でどのように見えるかをお見せしましょう｡ そして､ リソースの下に､ トラックの下に､ 私が作成した一連のテストファイルがあります｡ 各ファイルは1台の車両を表します｡ 車名はあくまでファイル名であり､ これからフロントエンドにこの車名が登場することになります｡ もし､ これにさらに車を追加したい場合は､ 新しいファイルを作成し､ このディレクトリに新しいファイルを作成するだけでよいのです｡ 緯度と経度､ つまり地球上の位置がずらっと並んでいるだけです｡ このファイルは､ ネット上のさまざまな情報源から入手したGPSの軌跡をもとに作成したものです｡ 位置シミュレータがこれらの緯度経度を読み込むたびに､ 当然ながらそれを使って何かする必要があります｡ マイクロサービスの目的の1つは､ 1つのマイクロサービスは1つのことしかできないようにすることです｡ さて､ ポジションシミュレーターの場合､ そのひとつはもちろんポジションをシミュレートすることになります｡ ファイルからこれらの位置のいずれかに読み込まれたら､ 本当にこのマイクロサービスの仕事は終わりです｡ だから､ そのデータをどこかに渡す必要があるのです｡ そのマイクロサービスがシミュレーションしたポジションを生成すると､ そのポジションをキューに送り出すわけです｡ そしてキューは､ マイクロサービス・アーキテクチャでは非常に一般的な側面です｡ マイクロサービスを結合させることなく､ システム全体でデータを送ることができるのです｡ 今回のシステムでは､ ActiveMqというキューを使用しています｡ このキューに出会ったことがあるかどうかはわかりませんが､ ここではいろいろな選択が可能です｡ 私はたまたまActiveMqに精通していて､ 非常にシンプルなキューを扱うことができます｡ キューは､ 他のシステム同様､ Dockerコンテナとして実装されています｡ K8s-fleetman-queueというこれです｡ GitHubにアクセスすると､ キュー用のフォルダも用意されていることがわかります｡ これは､ Dockerファイル1つだけなので､ このシステムのコンポーネントの中では圧倒的にシンプルです｡ Dockerファイルを見ると､ このコンテナはApacheから標準でダウンロードしたものをビルドしています｡ オルグ 次のマイクロサービスはポジショントラッカーと呼ばれるもので､ 確かにこのシステムにとってこれはマイクロサービスの中で最も重要なものです｡ このマイクロサービスの仕事は､ キューからポジションを読み込んで､ そのポジションに対して様々な計算をすることです｡ 例えば､ 車の速度を計算するようなことになりますね｡ また､ このマイクロサービスは､ 車両のリポジトリを形成し､ 車両がどこに行ったかという履歴を保存することなどができるようになっています｡ この点については､ コース後半でデータベースを扱うようになったときに詳しく説明する予定です｡ アニメーションで見たように､ データ､ 車両の位置はこの方向に向かっているのに､ 矢印はキューに向かっていることにお気づきでしょうか｡ さて､ 以前の講座でこの図を使ったとき､ 多くの質問がありました｡ この矢印がどっちを向いているのか､ これまで全く分からなかったのですが､ 技術的には､ ここで使っている表記法であるUMLでは､ 矢印は依存関係を示しています｡ そして､ このマイクロサービスはキューに依存しているので､ この矢印で表現しています｡ 実際にはデータの流れの方向を表現しているわけではないのですが､ ご理解いただけたでしょうか｡ この3つのコンポーネントが､ このシステムのバックエンド全体を表しており､ シンプルなシステムになっています｡ もちろん現実にはもっとたくさんのマイクロサービスを持つことになりますが､ このシステムにはこれだけで十分です｡ もちろん､ これらすべてのフロントエンドを用意することになりますが､ 今回のシステムでは､ JavaScriptのアプリケーションを使用することになります｡ たまたまAngularを使って実装されています｡ さて､ 最後に必要な主要コンポーネントは､ いわゆるAPIゲートウェイと呼ばれるものです｡ これが必要な理由は､ もちろん､ 左側のJavaScriptアプリケーションがバックエンドシステムと通信する必要があり､ これらのマイクロサービスと通信する必要があるからです｡ そして､ ここでJavaScriptのコードがマイクロサービスのどれかを直接呼び出すことを許したら､ それは間違いなく悪いことです｡ 理由は､ バックエンドのシステムがバージョンアップや修正され､ 一般的に設計されるようになると､ マイクロサービスも常に変化することになるからです｡ マイクロサービスは非常に小さいので､ 変更があるのは避けられないということを忘れないでください｡ このポジショントラッカーはどんどん複雑になっていき､ すぐにそのマイクロサービスを別のマイクロサービスに分けたくなることが想像できるのです｡ また､ その逆もあり､ 2つのマイクロサービスが小さすぎて､ 統合する必要があると気づくこともあります｡ だから､ バックエンドは常に変化し続けることになる｡ さて､ フロントエンドのJavaScriptがこれらのマイクロサービスを直接参照できるようにすると､ もちろん､ これらのマイクロサービスに変更を加えるたびに､ JavaScriptのコードをすべて調べ､ 関連するすべての変更を加えなければならなくなります｡ だから､ それは間違いなくアンチパターンと言われるもので､ フロントエンドのコードがマイクロサービスを直接参照することは絶対に許さないんです｡ そのため､ APIゲートウェイと呼ばれる最後のコンポーネントを導入しています｡ APIゲートウェイの考え方は､ とてもシンプルです｡ これがアプリケーション全体への入り口となる｡ 今後､ JavaScriptのコードは､ このAPIゲートウェイを参照することだけが許可されるようになります｡ APIゲートウェイは､ 非常にシンプルなコンポーネントです｡ その仕事は､ あらゆる呼び出しを適切なマイクロサービスに委ねることである｡ そして通常､ APIゲートウェイには､ 入ってきたリクエストを基礎となるマイクロサービスにマッピングする､ ある種のロジックが含まれています｡ つまり､ このJavaScriptは､ あるURLに対してrestコールを行うかもしれません｡ restコールである必要はありませんが､ そうすることもできます｡ APIゲートウェイのロジックは､ 通常､ 何らかのマッピングを行います｡ つまり､ 受信したリクエストの末尾が/vehiclesであれば､ その呼び出しを､ この場合はポジショントラッカーに委ねるというようなことです｡ つまり､ マイクロサービスのエンジニアが､ 新しいマイクロサービスを追加したり､ マイクロサービスを分割したりしても､ エンジニアは､ この非常にシンプルなAPIゲートウェイに対応する変更を加えるだけでいいということです｡ そして､ フロントエンドは､ いかなる変更からも隔離されます｡ さて､ ここで悩むのは､ APIゲートウェイをすでに知っている人も多いだろうし､ 初めての人も多いだろうから､ ここでレベルを正しく伝えるのは難しいのだが､ もしこれ以上の情報が欲しいなら､ ここで紹介しているURLをチェックしてほしい｡ これはAPIゲートウェイ・パターンの素晴らしい紹介だ｡ ですから､ システムの深い実装の詳細を知る必要はなく､ システムを展開することだけが仕事であることを忘れないでください｡ これで5つのDockerイメージのそれぞれの目的がわかったので､ これをKubernetesのデプロイに回してみましょう｡