Internal Developer Platform についてまとめてみる

概要

Internal Developer Platform (IDP) に関して以下のサイトの内容を参考にまとめたものをせっかくなのでQiitaに起こしたものになります。
(メモから起こしたものなので、言い回し等のバラつきはご容赦ください)

本記事の対象

• PlatformEngineeringに興味がある方
• IDP最近聞くけど何なのか気になっている方
• IDP関連のソフトウェアを触っている方

Internal Developer Platform とは

概要

IDPは開発者がスムーズに作業できるようガイドラインを提供し、開発者自身でサービス化までを実現できるようなプラットフォームを指す。
実態としては様々な技術やツール (CI Tool や Developer Potal など) によって構成されているもので、やりたいことに合わせて色々な構成パターンがあるもよう。
基本的にはソフトウェア開発のプロセスを効率的にするためにデザインをされる。

IDPの構築や保守はPlatformEngineeringチーム (もしくは運用チーム) にて実施し、開発者を顧客として扱い要望を吸い出して継続的に改善を続けていく。

なぜIDPを使うのか

IDPを構築して使う目的としては開発者のセルフサービス実現という点が大きなものとして挙げられます。
IDPでは開発者が自らサービスやアプリケーションを構築して、デプロイするためのツールやプロセスを提供します。
これにより、開発者はオペレーションに依存せずにアイディアからプロダクションまでのサービスやアプリケーションを構築できるようになる形になります。
つまりは、開発者が思いついたアイデアをすぐにテストして、どんどん発信していけるような環境を提供することを1つのゴールとしているイメージです。

開発者のセルフサービス実現の例としては以下のようなアプローチがされているようです。
（基本的にはテンプレートや自動化などを用いて開発プロセスの標準化という部分に重きをおいていそう）

簡易的かつ迅速なプロジェクト開始

IDPでは、開発者が簡単かつ迅速に新しいプロジェクトを開始できる環境を提供します。
実際にはダッシュボードなどから事前に定義したテンプレートなどを取得して、それらを用いるイメージ。
これによって開発者は手間のかかるセットアップ作業を回避し、アイデアを即座に具現化できるように。

デプロイと管理の簡素化

IDPにはKubernetes環境やCI/CDツールを組み込んでいることもあり、開発者が簡単にアプリケーションをデプロイすることが可能に。
これによりデプロイを簡略化して効率の向上に寄与している。

可視性の向上

プロジェクトの進捗やでデプロイ状況などをリアルタイムで可視化するダッシュボードを提供している。
ダッシュボードの名称としては、Internel Developer Portalとよく呼ばれるもののもよう。(これも略称IDPだから名前ややこしい)
実際のツールとしてはBackstageなどがよく採用されており、基本的にはカスタマイズして自由につかっていくもよう。

IDPの5つのコアコンポーネント

IDPでは以下5つのコアコンポーネントをカバーするように構築を行うのが必要なもよう。
「IDPを構成するならこのあたりはしっかり抑えておこう！」といった指標や考え方のようなイメージです。

• Application Configuration Management
• Infrastructure Orchestration
• Environment Management
• Deployment Management
• Role-Based Access Control

Application Configuration Management (アプリケーション構成管理)

IDPではアプリケーションの設定をコードとして標準化して管理させている。
(YAMLのマニフェストをたくさん管理するのは確かに大変。。)
コードで管理するにあたり以下のようなアプローチを意識して構成する必要がある。

Scope

IDPではコンテナ内のリソースと外部で実行されるリソースの双方を包括的に管理させる。
昨今のアプリケーションは内外両方のリソースを必要とするため、それらを動的に管理できるようにさせる必要がある。

Versioning

IDPでは基本的にアプリケーション設定等をバージョン管理させるような構成にしておく。
これにより、変更のトラッキングや管理が容易にさせることが可能となる。

Portability

IDPを全体の単一障害元にしないようにするためにPortabilityが大事。
マニフェストなどをファイルシステムやGitリポジトリなどに保存するようにすることで、IDPが利用できない状況でもシステムが停止しないで運用を継続できるような構成にする。

Secrets Management

IDPではSercret (秘密情報や認証情報等) の管理をセキュアに行えるようにさせる。
例えば誤って、gitリポジトリ等に秘密情報がコミットされてしまうリスクなどを低減させるようにする。

Infrastructure Orchestration

IDPでは開発プロセスで用いられる既存のツールやインフラストラクチャのすべてを統合してCI/CDプロセスまでを実現できるようにさせる。
例えば、デプロイ先に用いるKubernetesクラスタや、CI/CDパイプライン、DNSなどをIDP上に統合して利用できるようにさせるイメージ。

画像引用元

IDPに統合するにあたり以下のようなアプローチを考慮する必要がある。

CI/CDパイプライン

CI/CDパイプラインは基本的には時間を要するプロセス。
そのため、設定したあとは本当に必要な場合を除いて触れないようにする。

Kubernetesクラスタ

より最適にする場合は、必要に応じて削除可能なSA (サービスアカウント) を介するアクセス制御を行うようにする。

Environment Management

IDPを用いることで開発者がセルフサービスで環境を用意できるようにする。
新しい環境のセットアップにあたり、都度他の誰かが構築をする状態では手間やコストがかかってしまいます。
IDPではその点を払拭できるような構成として作成を行うことで、コスト削減等に寄与させる。

アプローチとしては前述のApplication Configuration ManagementやInfrastructure Orchestrationにて実施するイメージ。

画像引用元

Deployment Management

IDPではデプロイにおいて以下3つの要素を実現させて利用することが望ましい。

デプロイ自動化

チームがCD (継続的デリバリー) のプロセスを確立できるようにIDPは自動化の役割を提供する。
開発者がよりコードに集中するために、デプロイまでの多くの工程を自動化させることが望ましいこともあり、IDPでその点を実現できるようにする。

デバッグサポート

自動化したデプロイなどが失敗した場合のデバッグを円滑に実施できるようにさせる。
例えばデプロイのログや、コンテナログなどを統合してビューとして提供できるようにすることで、デバッグの起点として調査等を円滑にさせるようにさせる。

Versioning

デプロイのバージョンをIDPで管理できるようにする。
例えば複数のデプロイの中身を即座に比較したり、どのバージョンがどこで実行されているかなどを確認できる形にする

Role-Based Access Control

IDPではPlatformEngineeringチームが細かなレベルでアクセス管理を行えるようにする。
IDPの利用者としては、インフラをセットアップするPlatformEngineeringチーム (もしくは運用チーム)、新機能を開発する開発者、リアルな環境で新しい機能をテストしたりするプロダクトマネージャーなどと幅広いです。
このように様々な役割を持つ人がIDPを使用するため、アクセス制御はIDPにおいて重要な項目になります。

特にIDPではRBAC (Role-Based Access Control)の考え方が重要になります。

RBAC

RBACを用いたアクセス制御を行うことが望ましいものとなります。
個々のジョブ機能ごとにRoleを用意して、権限はこのRoleに割り当てて利用する形にします。
そして利用者には1つ以上のRoleを割り当てて利用させます。
これにより周辺環境の変化などによった必要な権限の変化が発生した場合にも、個々のユーザー権限を変更する必要なくRoleの変更で済むため、非常にスケーラブルになります。

組織のRoleとアプリケーション固有のRole

Roleの考え方として、組織内での制御とアプリケーション固有での制御をそれぞれ意識して行えるようにすることが望ましいです。
組織ではMemberやManager、Adminといった形が例として挙げられます。
アプリケーション固有での制御ではViewerやContributor、Ownerなどが例に挙がります。
また、アプリケーションだけでなく、環境固有 (productionやdevelopment)のRoleも重要とされています。

IDPに組み込まれるツール

冒頭でも記載したようにIDPは様々なツールなどを組み合わせて構築されるプラットフォームです。
では実際にどのようなカテゴリのツールが組み合わされているのかも今回参考としたサイトに記載されていましたので、それぞれまとめてみます。

なお、各カテゴリで代表的なツールが紹介されており、詳細やドキュメントリンクなどもガッツリ書かれていたのでそれらは気になるツールがありましたらそれぞれリンク先にて確認いただければと思います。
(全然知らないツールなどもたくさんあり、それらは個別で触って記事にするかもです)

Platform Orchestrator

Platform Orchestratorsは、IDPの中心的な役割を果たしている部分で、Dynamic Configuration Management (動的構成管理)を実現している。
開発者とPlatformEngineeringチームとの間であらかじめ決めた標準を強制し、同時に開発者に様々な変更へのセルフサービスアクセスを提供するためのもの。
デプロイ対象とするクラウド環境や用いるデータベース、モニタリングツール、また認証などをあらかじめ取り決めておいて、それらを強制させるようなイメージ。

代表的なツールとしては以下が紹介されていました。

• Humanitec
• Massdriver

Dynamic Configuration Management
Humanitecのブログにて詳細が詳細されていましたので、そちらを参考いただくのが良さそう。
https://humanitec.com/blog/what-is-dynamic-configuration-management

Developer Portal

Developer Portalsは開発者がIDPにて提供される機能を用いたりするのに利用するためのダッシュボード的な位置づけ。
各種テンプレートの提供やガイドラインなどをこちらから確認したりすることができる。
Backstageなどを触ったことがある方ならイメージしやすいかなと思います。

代表的なツールとしては以下が紹介されていました。

• AutoCloud
• Compass from Atlassian
• configure8
• Cortex
• OpsLevel
• Port
• Roadie
• Spotify's Backstage.io

CD Operator

CD Operatorは継続的なデプロイプロセスを自動化して管理するためのツールの一部。
ここで細かく紹介する内容でもないため、省略しつつですが、基本的には本番環境への展開プロセスの自動化に寄与するようなツールのイメージです。

代表的なツールとしては以下が紹介されていました。

• Argo CD
• Flux CD
• Jenkins
• Kubevela

https://internaldeveloperplatform.org/cd-operators/
※本記事執筆時点ではまだ作成中のページのもよう

CI Tool

CI Toolはソースコードの変更などをトリガーにビルドやテストなどのプロセスの自動化を実現したりするツール。
ソースコードをリポジトリにプッシュしたことなどを起因に自動的に実行する仕組みによって、コードの品質確保などに寄与してくれるイメージです。

代表的なツールとしては以下が紹介されていました。

• Bytebase
• CircleCI
• Codefresh
• GitHub Actions
• Gitlab
• Jenkins CI

Database

細かいDatabaseの説明は省略で!!

なお、代表的なツールとしては以下が紹介されていました。

• Aiven
• AWS RDS
• Azure SQL
• Google CloudSQL
• MongoDB
• PostgreSQL

Kubernetes

Kubernetes自体の細かい説明は省略しますが、IDP自体はKubernetes上に行うのが一般的なようで、95％がKubernetes上に構築されているようです。
また、一部のIDPは、任意の変更をInfrastracture as Code（IaC）セットアップを介して適用するアプローチを採用するもよう。

Image Registrie

前述の通りIDPでKubernetesを用いるということで、コンテナイメージを格納しておくImage Registryも必要になる感じですね。

代表的なツールとしては以下が紹介されていました。

• Amazon Elastic Container Registry (ECR)
• Azure Container Registry
• DockerHub
• Artifact Registry | Google Cloud
• Container Registry | Google Cloud
• Harbor

In-Cluster Resource

Kuberbetesのクラスタ上に展開しておく一部サービスやリソースを指しているようです。
インメモリデータベースやメッセージブローカーなどなど。
IDPではこれらのリソースを開発者がセルフサービスで扱うようなイメージかと思います。

代表的なツールとしては以下が紹介されていました。

• Elastic
• MariaDB
• RabbitMQ
• Redis

Infrastructure as Code

インフラストラクチャのリソースをコードで定義して管理するためのツール (アプローチ) です。
IDPの使い方にもよりますが、アプローチ方法によっては用いる感じですね。

代表的なツールとしては以下が紹介されていました。

• Pulumi
• Terraform by Hashicorp

Infrastructure Control Plane

IDP内でインフラストラクチャの構築、デプロイ、メンテナンスを管理するための要素。
IDPにて提供される機能の中では、クラウドプロバイダの環境やオンプレミス環境のリソースの統合的な管理を可能にするもよう。
(ここは理解度が薄いため、ツール触って理解を深めたら追記予定)

代表的なツールとしては以下が紹介されていました。

• Nitric
• Upbound

Monitoring

アプリケーションやインフラストラクチャの健全性やパフォーマンスを可視化するためのもの。
リアルタイムでのアラートなどによって問題を早期に発見して迅速な対応を提供できる。

代表的なツールとしては以下が紹介されていました。

• Datadog
• Elastic
• Grafana
• Instana
• New Relic
• Prometheus

Security

IDPでももちろんSecurityは大事ということで一部ツールが紹介されていました。
Securityはここで紹介をするには重すぎるので、細かいところは省略します。

• Gremlin
• Selefra

まとめ

今回IDPについて紹介されているサイトを参考にまとめたものを記事としておこさせていただきました。
IDPってすごい考えること多いんだな、、、と思った反面多くの技術が使われており非常に勉強になる分野だなと感じられました。
ツールに関してほとんど触ったことがないものが多かったため、より理解を深めるために今後はそちらも触っていければと思います。
また、調べた知識をもとにIDPの考え方を意識しつつ、構築等にもチャレンジしていければと思います。

今回参考としたサイト自体はgithubにて公開されており、追加情報等をプルリクエストで募集されていました。