OSS ベースの自宅クラウドの構成
はじめに
クラウドといえば AWS, Azure, GC の 3 大クラウドプロバイダーが主流ですが、現在は様々な機能に特化したクラウドネイティブな OSS プロジェクトが盛んに開発されているため、それらを組み合わせることで自宅でも各ベンダーで提供されているようなサービスと同等の機能を持つクラウド環境を構築することが可能となっています。
今までいくつかのコンポーネント（主に CNCF のプロダクト）を記事にしてきましたが、個々の記事だけでは各コンポーネントが全体の内どのような機能を果たしているか見通しづらい部分もあります。
そこで、この記事では自宅で使用しているものや今まで記事にしたものについて、各コンポーネントを機能毎に分類してそれぞれの役割について俯瞰します。
機能別の分類図
早速ですが自宅で使っているものや記事にしたプロジェクトを機能毎に分類した図が以下になります（一部記事にしていないのも含む）。
各機能 (Provisioning や Monitoring 等) については独自の判断に基づいて設定していますが、CNCF Landscape の分類を参考にしている部分もあります。
機能別のコンポーネントの概要図。
今まで取り扱ったプロジェクトのロゴを並べるとそれっぽい感が出る。
Infrastructure
まず何をするにもコンポーネントを動作させたり作業を行ったりするサーバー(物理 PC や仮想マシンなど)やネットワーク、ストレージ等を備えた環境が必要になります。
自宅では openstack 上で物理 PC に仮想マシンを構成し、その上に kubernetes クラスタを構成し k8s 用の OSS を試す構成にしています。
Openstack
openstack はプライベートクラウド環境を構築するための仮想化プラットフォームです。openstack を利用することで物理 PC の上にスペックの許す限り複数台のハイパーバイザー型仮想マシンを構築することができます。
自宅の環境では minis forum のミニ PC 上で All-in-One の openstack を構築し、検証用の仮想マシンを動かしたり消したりしています。
openstack にもいくつか構築手段がありますが、 docker コンテナ化された openstack コンポーネントを Ansible でインストールする kolla ansible を使うのが一番楽かと思います。
Kubernetes
言わずと知れたコンテナオーケストレーションのスタンダードです。有名なので説明は割愛。
Provisioning
ここでの Provisioning は上記の openstack 上に VM やそれに付随するリソースを作成する作業を指します。様々な検証や運用を行う際には影響を最小限に抑えるため個々の環境を分離することが望ましいです (要らなくなったらすぐに削除して作り直せるし、既存の環境に影響が出ると復旧が面倒なため)。しかし、その度に VM の作成、削除や依存ツールのインストールを手作業で行うのは面倒なので処理を自動化する必要があります。
Provisioning や IaC の分野で広く使われている Ansible や Terraform には主に次のような特徴があります。
- 宣言的にリソースや処理を記述できる。
- 処理を何回やっても同じ結果が得られることが前提 (冪等性)。
- module が豊富に用意されているため処理を 1 から作る手間が少ない。大抵は標準の処理や community が管理しているモジュールやプラグインで対応可能。
自分で必要な処理を行うスクリプトみたいなものを書いてもいいのですが、上記の性質から処理の追加や管理が容易なので自宅の環境構築ではこれらを使っています。
Terraform
Terraform は IaC を実現するための有名なプロダクトです。Terraform Openstack provider を使うことで Openstack 上で仮想マシン等のリソースを作成できるので、予め決まったスペック、フレーバー、floating IP address 等のプロパティを指定した仮想マシンを作成したり、不要になった際にまとめて削除できます。
Ansible
検証用に作成した仮想マシンで検証用ツールのインストールやデバッグの効率化のための設定（シェル補完やホストの名前解決の設定など）を行うのに Ansible が有効です。
terraform でソフトウェアやミドルウェアの Provisioning を行うのは（できなくもないが）不便な点があるので、インフラの構築は terraform, ソフトウェア、ミドルウェアのセットアップやその他汎用的な自動化処理は Ansible というように使い分けています。
Repository
Repository はコードや資料、コンテナイメージの保管に使用します。
Gitlab
ソースコードなどを保存する git レポジトリ。有名なので説明は割愛。
Distribution
コンテナイメージを保管するためのプライベートレジストリ。元々は docker registry という名前でしたが、管理団体が CNCF に変わった際に Distribution という名称に変更されたようです。
docker で構築できるので、手っ取り早くプライベートレジストリを構築、使用する場合はこちらを使っています。
Harbor
harbor もコンテナイメージを保管するためのプライベートレジストリです。イメージ補完のコアな機能分は Distribution と同じですが、web UI やアクセスコントロール、イメージの脆弱性スキャンツールの統合など本番環境にも使える様々な機能がついています。docker や kubernetes で利用可能。
CI/CD
ここではビルド、テスト等の integration や対象環境へのデプロイを包括的に行えるツールやプラットフォームを CI/CD に分類しています。
Concourse
Concourse はクラウドネイティブな CI/CD プラットフォームであり、Github Action や CircleCI のようにコマンドベースで実行する処理を記述することで CI/CD を実現できます。
concourse について書いた記事は以下を参照。
Tekton
Tekton もクラウドネイティブな CI/CD プラットフォームであり、コマンドベースで実行する処理を記述することで CI/CD を実現できます。
tekton について書いた記事は以下を参照。
Argocd
Argocd も k8s で GitOps の理念に基づいたデプロイを実現するのにおなじみのツールです。
Flagger
k8s へのデプロイについて、少なくとも自宅環境ではマニフェストの手動デプロイや helm, Argocd 等を使ったデプロイで充分ですが、 Canary デプロイや Blue/Green デプロイ等のより高度なデプロイを試してみたい場合は Flagger が使用できます。
flagger について書いた記事は以下を参照。
Stackstorm
stackstorm はイベント駆動形で様々な処理や連携を行うワークフローエンジンです。CI/CD 専用というよりはもう少し汎用的な処理の自動化として利用できますが、イメージのビルドやテスト、デプロイ等も作り込むことによって可能なためここでは CI/CD に分類しています。
stackstorm について書いた記事は以下を参照。
Observability
クラウドの環境では多数の VM やコンテナといったワークロードが動作するため、それらが正常に動作することを保証するためにモニタリングが不可欠となります。
Logging
言うまでもないですがエラー発生時の原因分析、トラブルシュートやイベントの監視など様々な面でログ収集が重要です。基本的には VM や k8s に Logging エージェントを入れて別のログ監視基盤で一元管理する構成が基本になるかと思います。
Logging エージェントもいろいろ選択肢はありますが、以前の記事では Elastic stack の一部である Filebeat を使った方法について紹介しました。
Metrics
メトリクスも CPU, メモリ、ストレージ使用率やネットワークの IN/Out などワークロードの使用状況や状態変化を監視するのに重要です。
メトリクス収集エージェントもこれまた色々選択肢がありますが、現在は各種 exporter で公開されたメトリクスを prometheus を使って収集する方式が広く使われている印象があります。
以前の記事では prometheus と thanos で k8s のクラスタを収集する方式について記載しました。
Tracing
Tracing では opentelemetry を使って tracing データの収集を行い、jaeger で可視化する構成が広く使われている印象があります。記事は以下。
Profile
Observability の分野における Profile は継続的プロファイリング (Continuous Profiling) とも呼ばれ、アプリケーションのメモリや CPU 使用量、その他の情報を継続的に監視、分析する際に活用されます。アプリケーション全体のメモリや CPU などのリソース使用量はメトリクスで収集可能ですが、profile ではアプリケーション内の関数やパッケージ単位で使用されるリソースまで収集することができ、ボトルネックとなっている処理の特定や時間的にリソース消費が悪化する事象への対応など、特にアプリケーションを継続的に改善していく際に有用となります。
継続的プロファイリングが可能なものも様々な選択肢がありますが、Grafana が管理する OSS の Pyroscope について使用した際の記事を以下にまとめました。
Data Storage
Observability 内の各要素はデフォルトではデータを長期間保存するようになっていないものが多いため、収集したデータを長期間保存したり、一元管理・参照するためにはデータを保管するデータストレージが必要となります。
とはいっても、例えば filebeat の場合は elasticsearch でデータ保存する等、保存先としてよく用いられるデータストレージには定番のものが決まっているため、特に理由がない限りはそちらを使うのが良いと思われます（情報検索が容易なため）。
Elasticsearch
Logging の filebeat と tracing の jaeger に関してはデフォルトで Elasticsearch への送信をサポートしているため、データ保存先には Elasticsearch がおすすめです。
Elasticsearch 自身も強力な検索や分析、aggregation 機能を持ち、後述の kibana との連携で参照や可視化が可能です（機能が豊富すぎて使うのが大変ですが）。
Minio
prometheus 自体は 多種の Remote storage への書き込みに対応しており、この中に elasticsearch も含まれています。
一方、thanos はオブジェクトストレージにデータを長期保存する形式であるため、OSS のオブジェクトストレージである minio が使用できます。
また、minio 自体は S3 互換のオブジェクトストレージなのでメトリクス専門というわけではなく一般的なデータ保存先としても使用できます。
Rook
本番環境で稼働するような数千 ~ 台の大規模なストレージクラスタを構築・管理するための OSS 分散ストレージシステムで Ceph というものがあります。
Rook はこれのクラウドネイティブ版とも言えるようなシステムとなっていて、ceph をストレージプロバイダーとして k8s 上で分散ストレージシステムを構築できます。
Ceph Storage Provider
Rook orchestrates the Ceph storage solution, with a specialized Kubernetes Operator to automate management. Rook ensures that Ceph will run well on Kubernetes and simplify the deployment and management experience.
Rook を使うことで以下の主要なストレージを利用できるようになります。
- ブロックストレージ
- オブジェクトストレージ
- 共有ファイルシステム
Rook は CNCF の Graduated project になっていることからその成熟度具合も高いことが伺えます。
Visualization
Observability を考える上での重要な点として、蓄積したデータを必要な時に適切な形式で参照できるということも大切です。
データストレージの種類に応じてよく使用される分析・可視化ツールというのもだいたい決まっているので、こちらも特に理由がない限りはそちらを使うのが良いです。
Kibana
Kibana は elasticsearch とよく組み合わせて使用されます。kibana 自体が Elastic stack のプロダクトの一部であるので elasticsearch との親和性が良く、蓄えられたデータを様々条件で参照・分析できます（こちらも機能が豊富すぎて使うのが大変）。
Grafana
Grafana は prometheus (thanos) とよく組み合わされて使用されます。prometheus のメトリクスを検索する PromQL を使用して必要なメトリクスをフィルタしたり独自のダッシュボードを作成して必要な情報のみを柔軟に可視化することが可能です。prometheus の他、Relational DB や Time Series DB など 多種のデータソースにも対応しています。
OpenObserve
OpenObserve は軽量版 Elasticsearch + kibana とも言える位置づけで、log, Metrics, trace データの保存・可視化が可能なプラットフォームになっています。目的を上記に絞ることによって本家 Elasticsearch と比べて学習・運用コストで利用することが可能です。
Network
Traefik
Traefik proxy はモダンで多機能な OSS の proxy サーバーです。nginx のように別サーバーへの proxy や負荷分散、ユーザー認証を行うことができ、k8s で使用する場合は ingress controller としても使用できます。nginx から web サーバーの機能を抜いた代わりに構成を yaml で設定することで管理しやすくしたような使用感となっています（あくまで個人の感想）。その他に TCP, UDP, gRPC のプロキシや LoadBalancing の機能の備わっています。
Traefik について書いた記事は以下を参照。
CoreDNS
CoreDNS は DNS と Service Discovery の機能を持ちます。
kubeadm 等で k8s クラスタを作成するとデフォルトでクラスタ内の DNS に使用されますが、別途構築して DNS サーバーとしても使用することができます。
Linkerd
Linkerd は k8s クラスタ内の Service mesh を実現するための proxy です。
Service mesh の分野では Istio が有名ですが、linkerd も CNCF Graduated project となっているためプロジェクトの成熟度は高く、利用者が多いことが伺えます。
Security
近年では DevSecOps のような用語もあるように言わずもがな Security は重要ですが、自宅の環境をネットワークに公開しない場合には正直そこまで気にしなくてもいい感はあります。
とはいえ重要であることは変わりないので、本番での運用を意識するような場合は Security 面にも意識を配る必要があります。
Trivy
Trivy はコンテナイメージの脆弱性検出や IaC、マニフェストファイルの不備をスキャンするための OSS ツールです。
Trivy について書いた記事は以下を参照。
Tetragon
Tetragon は eBPF を使用して対象環境のセキュリティや可観測性を高めるための OSS プロジェクトです。eBPF を利用することでコンテナランタイムのセキュリティ保護、独自ポリシーの適用などを実行し、3 代用ではカバーしきれない領域のセキュリティを貯めることが可能です。記事は以下。
Development
Backstage
Backstage はソフトウェアの依存関係やコード、インフラなどを一元に管理するための開発者ポータルを構築する OSS フレームワークです。
管理するツールが増えてくるとそれぞれの依存関係を把握するのが大変になり、開発を進めるために多数の UI やドキュメントを横断する必要があります。Backstage ではそうした情報をポータルと呼ばれる webUI に集約し、開発作業をより効率的に進められるような経験を提供します。
分野としては Platform Engineering に分類され、組織内で複数のチームが複数のソフトウェアを開発しているような場合に各ソフトウェアの依存関係や周辺ツールの情報、管理チームなどを明確にできるといったメリットがあります。また開発者ポータルを構築できる OSS はそれほど多くないため、ベンダーに依存せず無料で使用できる、plugin を自分で開発して機能を拡張できるといった点も強みとなっています。
Backstage について書いた記事は以下を参照。
Other
上記のカテゴリに当てはまらないものは other に分類しています。
Litmus
Litmus は k8s クラスタ上に意図的に障害を注入し、現構成の可用性や回復力を評価するためのカオスエンジニアリングフレームワークとなっています。
カオスエンジニアリングが自宅環境で必要になることはほぼないと思いますが、対象の pod に負荷をかけたり node を落としたりとなかなか面白い動作を試すことができます。
また、大規模な環境で実際にカオスエンジニアリングを取り入れている企業もあるため、それらの雰囲気を掴むためにやってみるのもあり。
Litmus について書いた記事は以下を参照。
k8sGPT
k8sGPT はパプリックサービスやローカルの LLM を利用して k8s クラスタ内のトラブルシュートやセキュリティ強化を補助するサービスです。
まだ CNCF Sandbox project ではありますが、AI を使って k8s をより効率的に管理していくサービスは目新しいので今後の発展が期待されます。
Identity Management
サービスが増えるにつれてユーザーやグループ、認証情報などの管理はより大変になっていきます。例えば、概要図の中では gitlab, harbor, stackstorm, elasticsearch, minio, grafana が内部てユーザー情報を管理するサービスとなってますが、新しいユーザーを追加したくなった時にそれぞれのアプリケーションに個別にユーザを追加したり、ユーザの役割に応じたロールやパーミッションを設定する、ユーザーのパスワードを更新する際に新しいパスワードを反映させる、不要となったユーザーを各サービスの登録情報から削除するといった作業はかなり面倒な工程になってきます。
そのため、サービスや組織の規模の拡大に合わせて、このようなユーザーやそれに付随するグループ等の情報、アクセス制限といった Identity を効率的に管理するためのアプリケーションの重要性が増してきます。
LDAP
LDAP はサーバー内で管理されるユーザーを効率よくクエリするためのプロトコルであり、これを利用してユーザーや組織を一元管理する機能を持つアプリケーションやソフトウェアは LDAP サーバーと呼ばれます。Active Directory のようにユーザーを一元管理し、ユーザーの固有情報 (~ identity) に基づいて関連サービスと統合することで効率的な運用を実現するのに役立ちます。
LDAP サーバーにはいくつか種類があり、それぞれ機能や特徴が異なります。
- OpenLDAP
- FreeIPA
- 389 Directory Server
- LLDAP
上記のうち LLDAP について書いた記事は以下を参照。
Authelia
Authelia は認証・認可サーバー、アクセスコントロール、OpenID Connect によるシングルサインオンなどの機能を有するアプリケーションです。LDAP と組み合わせてユーザーを効率的に管理し、OpenID Connect で各アプリケーションと連携することで管理の手間を軽減することができます。
Authelia について書いた記事は以下を参照。
Hashicorp Vault
Hashicorp Vault はユーザーのパスワードを始めとした各種機密情報を保管する Secret Manager です。サービスが増えるに連れて管理者ユーザーのパスワードやサービス間認証に使用する情報、証明書、トークンなど厳密に扱うべき情報も増えますが、それらを一元的に管理・保護することができます。
Vault について書いた記事は以下を参照。
Multi-cluster Management
シンプルな構成や運用の場合は単一のクラスタで充分なケースも多いですが、より大きなワークロードを運用していく場合、複数の k8s クラスタを合わせて運用するマルチクラスタや複数のクラウド上のクラスタを利用するマルチクラウド、ハイブリッドクラウドなど、複数のクラスタを扱うような需要も増えています。複数のクラスタを利用することでスケジューリングの最適化、災害対策、可用性の向上など多くのメリットがありますが、その一方で同時に管理対象が増えることによる管理の複雑さも増してきます。そのため、複数のクラスタを効率的に管理するツールが重要になってきます。
主要クラウドではそのクラウドのマネージド k8s サービスを利用することが想定されているため複数クラスタを管理できる機能は少ないですが、一方で OSS ではベンダーロックインを避けるためか様々な環境上のクラスタに対応しているプロダクトが多いです（といっても EKS, GKE, AKS, オンプレクラスタ(ベアメタルクラスタ)が多いですが）。
Rancher
Rancher は複数クラスタの管理やクラスタの作成、リソースの監視などを行うための統合的なプラットフォームです。
主要パブリッククラウドのマネージドクラスタサービスやベアメタルクラスタなどにサポートしており、クラスタ全体のリソース使用量の監視、ワークロードやネットワーク関連のリソースの一覧表示など各クラスタの使用状況を単一のプラットフォームで一元的に把握・管理できるようになっています。また、kube-metrics-stack や Istio 等の他ツールとも統合されており、メトリクス監視やサービスメッシュ構築など複数のクラスタを運用していく上で必要不可欠な要素も簡単に組み合わせることができます。
Rancher について書いた記事は以下を参照。
Karmada
Karmada は k8s マルチクラウドおよびマルチクラスタ管理システムです。クラウドプロバイダーに依存せず複数の k8s クラスタを管理でき、複数クラスタへのアプリケーションのデプロイ、クラスタ間 Failover などを実現できます。
Karmada について書いた記事は以下を参照。
おまけ
AWS サービスとの対応
紹介した OSS の機能と AWS のサービスを対応付けると表のようになります。
機能的にやや微妙なものは ? にしてます。
| OSS | AWS Service | 機能 |
|---|---|---|
| Tekton Concourse |
CodeBuild | CI |
| ArgoCD Flagger |
CodeDeploy | CD |
| GitLab Gitea |
CodeCommit, etc | Code Repository |
| Harbor Distribution |
ECR | Container Registry |
| StackStorm | EventBridge, Step Functions, etc | Event-driven workflow |
| Kubernetes | EKS | Container orchestration |
| Rook | EBS S3 EFS |
Storage |
| Minio | S3 | Object Storage |
| Elasticsearch, Kibana OpenObserve |
OpenSearch | Distributed search and analytics engine |
| OpenTelemetry | AWS Distro for OpenTelemetry | Trace |
| Tetragon | ? | eBPF |
| Pyroscope | CodeGuru Profiler? | Profiler |
| Ansible | System Manager? | Provisioning |
| Terraform | CloudFormation, etc | IaC |
| Trivy | ECR Image Scan, etc | Vulnerability Scanner |
| Litmus | Fault Injection Service | Chaos Engineering |
| LDAP | ? | Authentication and Authorization |
| Authelia | Cognito?, IAM? | Authentication and Authorization |
| Hashicorp Vault | Secrets Manager | Secrets Management |
| CoreDNS | Route 53 | DNS |
| Linkerd | App Mesh? | Service Mesh |
| Traefik | ELB? | Proxy, LoadBalancer |
おわりに
自宅の環境や記事にしてきたコンポーネントを機能別に分類し、それぞれの役割や立ち位置について整理しました。俯瞰的に見ることで各コンポーネントがどの領域の機能をカバーしているのか、どの機能が不足しているのかが視覚的に認識することができます。
クラウドベンダーのサービスは基本的に使う分だけ課金される一方、自宅クラウドはいくら使っても無料です（PC の電気代はかかりますが）。CI/CD や Observability を試してみたいけど費用が気になるという人や自分で手を動かしてサービスの仕組みを理解したい人は自宅クラウドの構成を検討してみるのもいいかもしれません。
Discussion