ぼくのかんがえたさいきょうのDevOps実現構成
はじめに
昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。（たくさんの方に見ていただき感謝してます！）
本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。
前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。
また、こちらの記事は 2024 年 3 月時点での情報です。料金改定により、コストパフォーマンス悪くなったり、新たに便利なサービスが登場する可能性もあります。
全体図
こちらが「ぼくのかんがえたさいきょうの DevOps 実現構成」の全体図です。簡単に説明すると「GitHub + α」⇄「Grafana Cloud + α」で Dev ⇄ Ops のループを回す構成を表しています。
※クリックで拡大
できるだけ費用を抑え、かつ便利な SaaS を選択しました。今回は DevOps を実現する構成として様々なツールを紹介しますが、あくまでもツールは DevOps の手段であって、ツールの導入だけでは DevOps を実現できません。
まずは DevOps について解説していきます。
DevOps とは
DevOps とは、ソフトウェアの開発（Dev）と運用（Ops）の壁を取り除いてフレキシブルかつスピーディーに開発することで、システムの継続的な向上・改善を目指す文化や技術、プロセスのことを指します。
DevOps が実現できていると、Plan → Code → Build → Release → Deploy → Operate → Monitorのプロセスを繰り返して、システムの向上・改善を素早く行うことができます。
これだけでは DevOps に具体的にイメージしづらい思うので、DevOps の指標をいくつか紹介します。それぞれ共通する部分が多いのでイメージしやすいのではないでしょうか。
DevOps と「CALMS」
組織が DevOps を導入する能力を評価するためのフレームワークとして「CALMS」と呼ばれるものがあり、下記の 5 つの頭文字から名付けられています。
Culture（文化）
組織文化の変革を促す。
Automation（自動化）
手作業のプロセスを自動化して速度と信頼性を向上させる。
Lean（無駄がない）
開発フローを改善して無駄を削減し、価値の提供を最大化する。
Measurement（計測）
パフォーマンス指標やフィードバックループを活用して、継続的な改善を促進する。
Sharing（共有）
知識や情報を共有する。
DevOps の「3 つの道」
「The DevOps 逆転だ！究極の継続的デリバリー」や「The DevOps ハンドブック 理論・原則・実践のすべて」では DevOps の行動原理はすべてこの 3 つから導き出せるとして、下記の 3 つを挙げています。
フローの原則
開発 → 運用 → 顧客のワークフローを高速にする。
フィードバックの原則
すばやくてコンスタントなフィードバックフローを実現する。
継続的な学習と実験の原則
成功と失敗の両方から組織として学習し教訓を得ていく文化を育む。
DevOps の「4 本柱」
「Effective DevOps」では効果的な DevOps のための 4 本柱として下記の 4 つを挙げています。
コラボレーション
チーム間の壁を取り除き、オープンなコミュニケーションと協力を促進する。
アフィニティ
共通の目的やゴールに向かってチームが一丸となる。
ツール
適切なツールを選定して利用する。
スケーリング
DevOps 文化を組織全体に拡大する。
DevOps の「Four Keys」
DevOps Research and Assessment（DORA）チームは、6 年間の研究を基に、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標として下記の 4 つを挙げています。「Lean と DevOps の科学」という書籍でも紹介されています。
デプロイの頻度
正常な本番環境へのリリースの頻度。
変更のリードタイム
commit から本番環境稼働までの所要時間。
平均復旧時間
本番環境での障害から回復するのにかかる時間。
変更失敗率
デプロイが原因で本番環境にて障害が発生する割合。
2017 年時点で、パフォーマンスが低い組織と比較して、パフォーマンスが良好な組織は次のとおりになったそうです。
- デプロイの頻度が 46 倍（1 日複数回）
- 変更のリードタイムが 1/440（1 時間未満）
- 平均復旧時間は 1/170（1 時間未満）
- 変更失敗率は 1/5（0-15％）
DevOps の能力（ケイパビリティ）
またDevOps Research and Assessment（DORA）チームは他にも、ソフトウェア デリバリーと組織のパフォーマンスを改善するための能力を調査・検証し、DevOps のケイパビリティとして公開しています。
DevOps のケイパビリティは技術に関するケイパビリティ・プロセスに関するケイパビリティ・文化に関するケイパビリティの 3 つに分類されており、全部で 27 のケイパビリティが紹介されています。「Lean と DevOps の科学」という書籍でも紹介されていますが、こちらの書籍の発売時（2018 年）は 24 個でした。
技術に関するケイパビリティ
- クラウドインフラストラクチャ
- コードの保守性
- 継続的デリバリー
- 継続的インテグレーション
- 継続的なテスト
- データベースのチェンジマネジメント
- デプロイの自動化
- チームのツール選択をサポート
- 疎結合アーキテクチャ
- モニタリングとオブザーバビリティ
- セキュリティのシフトレフト
- テストデータ管理
- トランクベース開発
- バージョン管理
プロセスに関するケイパビリティ
- 顧客からのフィードバック
- システムをモニタリングして的確な判断
- 障害の予兆通知
- 変更承認の効率化
- チームのテスト
- バリューストリームでの作業の可視性
- ビジュアル管理機能
- 仕掛り制限
- 小さいバッチ単位の作業
文化に関するケイパビリティ
DevOps のアンチパターン
「Effective DevOps」には DevOps のアンチパターンとして下記の 4 つが紹介されています。
非難文化
エラーやインシデントの原因を作った人を非難し処罰する。
サイロ
同じ企業の他のチームと知識を共有しない。
根本原因分析
直接の原因ばかりが注目されて、間接的に影響を与えたかもしれない要素が目に入らなくなる。
ヒューマンエラー
ミスを犯した人がエラーの直接的な原因にする。
また、オライリーの「システム運用アンチパターン」にて、
本書は、一般のエンジニアやチームリーダーが DevOps による変革を起こすための手助けになるよう書かれたものです。
との記載があるので、こちらの書籍で紹介されているアンチパターンも紹介します。
パターナリスト症候群
仕事の進め方やタイミングを権力の持つ人に委ねる。
盲目状態での運用
システムが期待通りの処理が行われているかどうか確認するためのツールを使用せず運用する。
情報ではなくデータ
利用者を考えたダッシュボード作成をしていない。
最後の味付けとしての品質
意味のないテストを行なっている。
アラート疲れ
ノイズになっているアラートが多すぎて重要なアラートに気付けない。
空の道具箱
運用が自動化されていない。
業務時間外のデプロイ
業務時間外にデプロイする。
せっかくのインシデントを無駄にする
インシデントを今後の改善に活かさない。
情報のため込み
情報を共有しない。
命じられた文化
組織の文化が形骸化している。
多すぎる尺度
作業の優先順位づけがされていない。
DevOps は”文化”
オライリーの「ソフトウェアアーキテクチャメトリクス」では、
DevOps の主要な焦点は文化であり、ツールや自動化はそれに続くものと言えます。
とあります。
また、「Effective DevOps」にも、
devops は文化運動である。あなたの環境において今使っているツールは、あなたの文化の一部である。
ツールは、現在の組織文化と方向性にもとづいて、改革を支え加速していく存在である。
とあります。
今回はツールの紹介となりますが、ツールの導入で満足するのではなく、ツールを通じて DevOps の文化を育むことが重要となります。
料金
今回紹介する SaaS の料金です。変動があるかと思うので公式サイトの料金ページの紹介に留めます。
それでは本構成について紹介していきます。
GitHub でソースコード管理
ソースコード管理は GitHub で行います。「DevOps のケイパビリティ」におけるバージョン管理に関するケイパビリティをサポートします。
GitHub
GitHubは Git を利用してコードの保存と公開が出来、他の開発者と一緒にコードのレビューをしたり、プロジェクトを管理しながら、ソフトウェアの開発できるサービスです。
コードの保守性 & 疎結合アーキテクチャ
「DevOps のケイパビリティ」にはコードの保守性が紹介されていました。Google では、「DevOps のケイパビリティ」の 1 つであるトランクベース開発や、全てのコードを 1 つのリポジトリに集約するモノリシックリポジトリを採用することで、コードの保守性を向上しているようです。
また、「DevOps のケイパビリティ」には疎結合アーキテクチャについても紹介されていました。「テスト容易性」と「デプロイ容易性」がパフォーマンスの向上に重要であり、この 2 つの特性を持たせるには、システムは疎結合である必要があると「Lean と DevOps の科学」に記載されています。
マイクロサービスアーキテクチャの採用や、マイクロサービスの境界を明確にするためのドメイン駆動設計(DDD)の採用が考えられます。
GitHub のデータを Grafana で可視化
Grafana には GitHub をデータソースとして利用できるプラグインが用意されており、GitHub のデータを可視化できます。
「DevOps のケイパビリティ」におけるバリューストリームでの作業の可視性に寄与し、「Four Keys」の 4 つの指標のうち、変更のリードタイムを把握しやすくなります。
SDK の導入
そして、今回の構成を実現するためにはアプリケーションに下記 4 つの SDK を導入する必要があります。
それぞれの SDK について紹介していきます。
OpenTelemetry SDK
OpenTelemetryはメトリクス・ログ・トレースなどのアプリケーションを監視するためのデータの収集を標準化するための CNCF のプロジェクトです。このプロジェクトの SDK を使用してアプリケーションのトレースデータを取得します。
トレースとは、メトリクスやログなどと同じくアプリケーションを監視するためのデータの 1 つで、メトリクス・ログ・トレースを３つ合わせてオブザーバビリティの 3 本柱と言われており、複数のサーバーを伝播する特定のリクエストの追跡データを取得します。
後述するGrafana TempoはこのOpenTelemetryに対応しているので、このOpenTelemetryの SDK からGrafana Tempoにトレースデータを送信します。
CNCF
CNCF(Cloud Native Computing Foundation) とは Linux Foundation のプロジェクトの 1 つで、クラウドネイティブなコンピューティングシステムを推進するための非営利団体の事です。今回の構成では CFCF のプロジェクトとして、他にもOpenFeatureやPrometheusを紹介します。
Pyroscope SDK
Pyroscopeは継続的プロファイリングを行うためのツールで、この SDK を使用してアプリケーションの継続的プロファイリングを行います。
継続的プロファイリングとは先ほどのオブザーバビリティの 3 本柱に次ぐ 4 本目の柱とも言われており、アプリケーションのどのコードがどの程度の CPU やメモリを消費しているか、実行時間がどのくらいかかっているかを把握するためのデータを取得します。
後述するGrafana Pyroscopeにプロファイリングデータを送信します。
Sentry SDK
Sentryは RUM (Real User Monitoring)やエラートラッキングを行うためのツールで、この SDK を使用してアプリケーションのエラートラッキングを行います。
RUM とはリアルユーザーの視点からアプリケーションのフロントエンドパフォーマンスを監視することです。また、エラートラッキングとはアプリケーションのエラーを監視することです。ログとの違いについてはこちらをご覧ください。
後述するSentryにエラートラッキングしたデータを送信します。
TEMPLE
OpenTelemetryやJaegerを作った人が提唱した概念で、オブザーバビリティの 4 つの柱にEventとExceptionを加えた 6 つの柱のことで、下記記事に詳しく書かれています。
記事でも紹介されている通り、Sentry はExceptionにあたります。
OpenFeature SDK
OpenFeatureはフィーチャーフラグの管理を標準化するための CNCF プロジェクトで、これに順守しているサービスであれば共通の SDK を使用してフィーチャーフラグを管理できます。
フィーチャーフラグは、コードを直接変更せずに、特定の機能をオンまたはオフにできる技術です。これにより、新機能を特定のユーザーのみに表示したり、AB テストなどの機能テストを行うことが可能です。「DevOps のケイパビリティ」における小さいバッチ単位の作業においてもフィーチャーフラグの使用が紹介されています。
後述するLaunchDarklyはこのOpenFeatureに対応しているので、LaunchDarklyを使用してでフィーチャーフラグを管理します。
GitHub Actions で CI/CD を実装
GitHub Actionsを用いて、継続的インテグレーション/継続的デリバリー（CI/CD）を行います。「DevOps のケイパビリティ」における継続的デリバリー・継続的インテグレーション・継続的なテスト・デプロイの自動化といったケイパビリティをサポートします。
GitHub Actions
GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる CI/CD サービスです。
今回の構成の CI/CD では下記の 5 つのステップを採用しました。
ここでは含めませんでしたが、後述する下記３つも GitHub Actions 上で実行可能です。
GitHub Actions のログを Grafana Loki に送信
GitHub Actions のログをGrafana Lokiに送信することで、ワークフローの実行時間やエラーの発生箇所を可視化できます。
また、メトリクスやアプリケーションログのデータと連携することで、デプロイによる影響も把握しやすくなります。
「Four Keys」の 4 つの指標のうち、デプロイの頻度や変更失敗率を把握するためにも有用です。
こちらを実行するための GitHub Actions のアクションを作成したので、是非ご活用ください。
フォーマット & 静的解析(Biome, etc.)
フォーマットはソースコードを整形することで、静的解析は文法上の誤りやバグの原因となるようなコードを解析することです。
JavaScript だとフォーマットにはPrettier、静的解析にはESlintが有名で、フォーマットと静的解析の両方が行えて、Prettier と ESLint との高い互換性のあるBiomeといったツールも注目を浴びています。
その他、Go 言語では標準でフォーマットや静的解析の機能が用意されていたり、Terraform では標準でのフォーマットと TFLint という静的解析ツールが用意されていたりします。
今回の構成ではBiomeを記載していますが、要件や言語によってその他のツールも考えられます。
単体テスト & 結合テスト(Vitest, etc.)
単体テストは関数やクラスが正しく機能するかをチェックするテストのことです。
JavaScript だとJestが有名で、 Jest と高い互換性があり Jest よりも高速なVitestといったツールも注目を浴びています。Go 言語では標準でテストの機能が用意されていたりします。
また、結合テストは複数の関数やクラスを組み合わせて、それらが連携して正しく動くかを検証するテストのことです。
JavaScript だとTesting Libraryといったツールが有名です。
このTesting Libraryですが、「Testing Trophy」というテストの考え方を提唱しており、「結合テスト」に最も比重を置くべきだとしています。
※Static が静的解析、Unit が単体テスト、Integration が結合テスト、E2E が E2E テストを表しています。
今回の構成ではテストのツール例としてVitestを記載していますが、要件や言語によってその他のツールも考えられます。
ビルド(Vite, etc.)
ソースコードから実行可能なプログラムを生成するプロセスのことです。
JavaScript だとwebpackというバンドルツールが有名ですが、新しいツールだとViteや webpack の後継であるTurbopackが webpack よりも高速で注目を浴びています。Go だと標準でビルドの機能が用意されていたりします。
今回の構成ではViteを記載していますが、こちらは言語やツールの好みよって変わってくるでしょう。
アプリケーションのデプロイ(Docker)
コードをサーバー上にアップロードして動かせるようにするプロセスのことです。
今回の構成ではコンテナを使用するアーキテクチャを想定しているので、デプロイのツールとしてはDockerを記載しました。他にもAWS CLIといったコマンドの使用やAnsible、AWS CodeDeployといったツールの使用、コンテナのアーキテクチャとしてKubernetesの使用も考えられます。
インフラのプロビジョニング(Terraform)
コードを使用してインフラストラクチャのプロビジョニングを行います。いわゆる Infrastructure as Code（IaC）です。
TerraformやAWS CDKといったツールの使用が考えられますが、AWS 以外の SaaS にも使用したいため、今回はTerraformを記載しました。
TerraformのフォークサービスのOpenTofuというツールも登場したので、今後はこちらが主流になっていく可能性もありますね。
Terraformは今回紹介する下記の SaaS に対応しています。
- Grafana Cloud
- AWS
- Checkly
- Sentry
- LaunchDarkly
Grafana Cloud でオブザーバビリティを向上
Grafana Cloudを使用して監視とオブザーバビリティを向上します。「DevOps のケイパビリティ」におけるモニタリングとオブザーバビリティやシステムをモニタリングして的確な判断・ビジュアル管理機能・障害の予兆通知といったケイパビリティをサポートします。
Grafana Cloud
Grafana Cloudは下記の７つのサービスを Grafana Labs がマネージドサービスとして提供している SaaS です。
- Grafana
- Prometheus
- Grafana Loki
- Grafana Tempo
- Grafana Pyroscope
- Grafana OnCall
- Grafana Incident
- Grafana k6
Datadog との比較
前回の記事では、運用コストを考えると Datadog に１本化した方がいいのではないかというコメントをいくつかいただいたきました。今回の構成でも Sentry と Checkly の機能は Datadog に 1 本化できますが、Grafana OnCall や Grafana k6 に変わる機能が Datadog には無いので、今回の構成と同様の領域をカバーしようと思うと Datadog に１本化は出来ないことが分かります。
また、OSS の運用コストについても指摘もいただきましたが、Grafana Cloud は OSS を SaaS としているサービスなので、特に OSS の運用コストは発生していません。以前の記事では「ベンダーロックインを最小限にして OSS を使用する」ということを強調していたためにそういう印象を抱いてしまったと思うので、今回は「SaaS を組み合わせて DevOps を実現する」に修正します。
Datadog もかなり便利ではあるのですが、今回の構成と同じことを Datadog で実現しようと思うとかなり料金が膨れ上がりますし、Grafana の方がダッシュボードやアラートの自由度が高く使いやすい印象です。
ダッシュボード（Grafana）
ダッシュボードは Grafana Cloud で提供されているGrafanaを使用します。
Grafana
Grafanaとは Grafana Labs が公開しているデータ可視化の OSS です。
Grafana は様々なデータソースを可視化できるので、この Grafana を使用して様々なデータを可視化します。
Grafana Cloud 内のサービスだけでなく、データソースとして下記のサービスに対応しています。
アラート
また、Grafana にはデータソースのデータに対して閾値を設定してアラートを送信する機能もあります。
後述するGrafana OnCallにアラートを送信することで、アラートを管理しやすくなります。
Grafana のダッシュボードを Slack に送信
せっかく Grafana でダッシュボードを作成しても、ダッシュボードを確認する機会というのは残念ながら少ないだろうと思われます。
ですが、 Grafana のダッシュボードのスクリーンショットを定期的に Slack に送信するようにすれば、ダッシュボードを確認する機会が増えるので、ダッシュボードの有効活用が期待できます。
2024 年 3 月現在、Grafana のダッシュボードのスクリーンショットを Slack に送信する機能というのは存在しませんが、メールで送信する機能は存在するのでこれを利用して Slack にダッシュボードのスクリーンショットを送信することが出来ます。
こちらのやり方についての記事を今後作成予定です。
メトリクス(Prometheus)
メトリクス監視では Grafana Cloud の一部の機能として提供されているPrometheusというツールを使用します。ちなみに Prometheus は Grafana Labs の製品ではありません。
Prometheus
Prometheusはメトリクスを収集する OSS で CNCF のプロジェクトです。Linux や Apache、MySQL 等のメトリクスを取得する様々な Exporter が用意されているので、目的に合ったメトリクスを収集することが出来ます。(Exporter は自分で作る事もできます。)
Prometheus の可視化には通常、Grafana が利用されます。
AWS のメトリクス
AWS のメトリクスの取得方法に関しては下記の公式ドキュメントを参照してください。
ログ(Grafana Loki)
ログ監視では Grafana Cloud の一部の機能として提供されているGrafana Lokiというツールを使用します。
Grafana Loki
Grafana Lokiは Grafana Labs が Prometheus を参考にして開発した、ログ収集を行う OSS です。
AWS のログ
AWS のログの取得方法に関しては下記の公式ドキュメントを参照してください。
トレース(Grafana Tempo)
トレース監視では Grafana Cloud の一部の機能として提供されているGrafana Tempoというツールを使用します。
前述のOpenTelemetry SDKからGrafana Tempoにトレースデータを送信します。
Grafana Tempo
Grafana Tempoは Grafana Labs が開発したトレース監視の OSS です。
継続的プロファイリング(Grafana Pyroscope)
Grafana Labs がオブザーバビリティの第４の柱と謳っている継続的プロファイリングを行うため、Grafana Cloud の一部の機能として提供されているGrafana Pyroscopeを使用します。
前述のPyroscope SDKからGrafana Pyroscopeにプロファイリングデータを送信します。
Grafana Pyroscope
継続的プロファイリングで有名なツールの Pyroscope が、Grafana Labs に買収されたことによりGrafana Pyroscopeになりました。
負荷テスト(Grafana k6)
システムに負荷をかけて、パフォーマンスの影響や不具合を確認するテストのことです。Grafana Cloud で利用できるGrafana k6を使用します。
Grafana Cloud 上のGrafana k6で実行するだけでなく、GitHub Actions 上で Grafana k6 CLI を動かして負荷テストを CI に組み込むこともできます。
※$ k6 runでローカルの実行、$ k6 cloudでクラウド上での実行ができます。
Grafana k6
JavaScript を用いて負荷試験のテストを行える k6 という OSS が、Grafana Labs に買収されたことによりGrafana k6になりました。
アラート管理(Grafana OnCall)
Grafana Cloud で使用できるGrafana OnCallを使用して Grafana や Sentry などのアラートを管理します。Webhook 受信もできるので、GitHub Actions の失敗を管理するような使い方もできます。
Grafana OnCall
Grafana OnCallは様々な監視ツールからのアラートを統合的に管理できる OSS です。Grafana のアラートだけでなく、AWS や Sentry 等のアラートにも対応しており、アラートの通知先には Slack 等のチャットツールや電話でのオンコールが利用できます。
重複したアラートをグルーピングする機能や、アラートの対応を記録できる機能があるので、ノイズになっているアラートが多すぎて重要なアラートに気付けないと言ったアラート疲れを防ぐことができます。
似たようなツールには PagerDuty や Opsgenie がありますが、Grafana OnCall はこれらのツールに比べて、費用が安いです。
インシデント管理(Grafana Incident)
せっかくのインシデントを無駄にすることが無いよう、Grafana Cloud で使用できるGrafana Incidentを使用してインシデントを管理します。
先ほどのGrafana OnCallやこちらのGrafana Incidentには、アラートやインシデントが Resolve になるまでの時間を計測する機能があり、
「Four Keys」の 4 つの指標のうち、サービスの復旧時間を把握するために有用です。
その他 AWS のデータを Grafana で可視化
AWS のセキュリティとコストのデータ(Amazon Athena)
AWS のセキュリティデータにはAmazon AthenaとAmazon Security Lake、コストデータにはAmazon AthenaとAWS Data Exportを使用します。
Grafana のデータソースプラグインとしてAmazon Athenaが用意されているので、これらのデータを可視化できます。
Amazon Athena
Amazon Athenaは SQL を使用して Amazon S3 内のデータを直接分析できる AWS のサービスです。これを使用して S3 に保存されているセキュリティデータやコストデータを参照します。
Amazon Security Lake
AWS Security Lakeは AWS Security Hub や AWS CloudTrail 等の様々なセキュリティログを Open Cybersecurity Schema Framework (OCSF)というオープンソーススキーマの形式で保存し、集約・管理できるサービスです。AWS 以外のサービスにも対応しています。
AWS Data Exports
請求やコスト管理に関するデータを S3 バケットに定期的に配信できます。
Athena のデータを Grafana で可視化
Grafana には Athena をデータソースとして可視化するためのプラグインが用意されています。
アプリケーションのデータ
運用上アプリケーションのデータを可視化したいケースもあるかと思いますが、様々な AWS サービスを Grafana のデータソースプラグインを使用して、可視化できます。
Amazon API Gateway, AWS AppSync のデータを Grafana で可視化
HTTP API や GraphQL 用の Infinity というプラグインを使用して可視化できます。
Amazon RDS のデータを Grafana で可視化
MySQL や PostgreSQL 用のプラグインを使用して可視化できます。
Amazon OpenSearch Service のデータを Grafana で可視化
Elasticsearch や OpenSearch 用のプラグインを使用して可視化できます。
その他 SaaS で DevOps を強化
GitHub や Grafana Cloud では補えない機能を、他の SaaS を使用して補完します。
セキュリティスキャン(Snyk)
セキュリティの脆弱性を検出し、アプリケーションの安全性を確保することです。Snykというツールを使用します。「DevOps のケイパビリティ」におけるセキュリティのシフトレフトに関するケイパビリティをサポートします。
GitHub Actions 上で Snyk CLI を動かして脆弱性スキャンを CI に組み込んだり、Web 上のSnykで定期的な脆弱性スキャンを行う事もできます。
※$ snyk testで脆弱性スキャンをローカル実行、$ snyk monitorで Web 上の Snyk にプロジェクトを作成して、継続的な脆弱性スキャンを行うことができます。
下記画像はアジャイルテストの４象限と呼ばれるものです。
非機能テストにはパフォーマンスやセキュリティのテストが含まれ、こちらをすでに紹介した k6やこのSnyk でカバーしています。
今回はSnykを使用しますが、その他にもTrivyや GitHub より提供されているDependabotやCodeQLといったサービスの利用が考えられます。
それぞれ脆弱性として認識される項目が違ったりするので、よりセキュリティを強化したいなら単体のツールを使用するのではなく、複数組み合わせてもいいでしょう。
Snyk
Snykはアプリケーションの脆弱性を検知するための SaaS で、以下の 4 つの機能があります。
- Snyk Open Source: オープンソースコードの脆弱性を検知
- Snyk Code: アプリケーションコードの脆弱性を検知
- Snyk Container: コンテナイメージの脆弱性を検知
- Snyk Infrastructure as Code: Kubernetes、Terraform 等の設定ファイルの脆弱性を検知
コードレビュー(CodeRabbit)
CodeRabbitを使って AI によるコードレビューをしてもらいます。「DevOps のケイパビリティ」における変更承認の効率化に関するケイパビリティをサポートします。
PR のレビューはレビュー側にも知識が必要ですし、規模の大きい PR はレビューをするのも大変なので、CodeRabbitを使って PR のレビューを効率化させます。
CodeRabbit
CodeRabbitは PR の要約と AI によるレビューをしてくれる SaaS です。
AI もまだまだ完璧ではないので、レビューを全てCodeRabbitに丸投げするというのは難しいです。
しかし、要約と AI によるレビューがあるだけで、PR のレビューをかなり効率化できますし、人間によるレビューだけの時よりもコード品質の向上に期待できます。
テストケースの管理(Qase)
Qaseを使ってテストケースの管理をします。「DevOps のケイパビリティ」におけるチームのテストに関するケイパビリティをサポートします。
単体テストや結合テスト、E2E テストを自動化させましたが、全てのテストを自動化できるわけではありません。また、手動によるテストによって自動テストでは明らかにならなかったような問題を発見できることもあります。
すでに紹介したアジャイルテストの４象限では、機能テストの一部や探索的テストは手動で行うものとされています。
スプレットシート等を使用するようなケースが多いかと思いますが、Qaseを使うことでテストケースの管理を効率化できます。
Qase
Qaseはテストケースの管理をするための SaaS です。
JestやPlaywrightのテスト結果をQaseに送信することも出来ます。
外形監視と E2E テスト(Checkly)
外形監視とは、外部からのユーザー視点でアプリケーションの監視をすることです。Grafana Cloud にも外形監視は用意されていますが、機能としてはまだ不十分なので、Checklyというツールを使用します。
また、E2E テストとは、ソフトウェアがエンドユーザーの視点で正しく機能するかを確認するテストのことです。
Playwrightといったツールが有名で、ChecklyというツールにはこのPlaywrightが組み込まれているので、E2E テストにもこのChecklyを使用します。
GitHub Actions 上で Checkly CLI を動かして外形監視と E2E テストを CI に組み込んだり(E2E テストに関しては直接 Playwight の CLI を動かすのでも可)、Web 上のChecklyで定期的な外形監視と E2E テストを行う事もできます。
※$ checkly testで外形監視と E2E テストをローカル実行、$ checkly deployで Web 上の Checkly にデプロイして、継続的な外形監視と E2E テストを行うことができます。
外形監視と E2E テストの違い
外形監視と E2E テストは似てますが、外形監視は実稼働環境でアプリを継続的にテストすることを目的としており、E2E テストはデプロイ前にバグを検出することを目的としています。
Checkly
Checklyは外形監視、E2E テストが行える SaaS です。E2E テストにはPlaywrightを使用します。
外形監視と E2E テストができる Checkly とは？という記事にて Checkly の機能について詳しく紹介しているので、こちらもご覧いただけると幸いです。
Datadog との比較
Datadog との比較はこちらのサイトをご覧ください。Checkly は Datadog と比較してかなり安価であることが分かります。
Checkly と Prometheus の統合
チェックの結果を Prometheus 形式のメトリクスとして出力できるので、Grafana にて結果を確認できます。
Grafana Cloud で Checkly の Prometheus エンドポイントからメトリクスをスクレイピングします。
エラートラッキング(Sentry)
前述のSentry SDKから RUM (Real User Monitoring)のメトリクスやエラートラッキングしたデータをこのSentryに送信します。
Sentry
Sentryはパフォーマンス監視やエラー監視を行うための SaaS です。
Sentry のデータを Grafana で可視化
Grafana は Sentry のデータソースプラグインが用意されているので、Sentry のデータを Grafana で可視化できます。
また Sentry のアラートを Grafana OnCall に送信できます。これで Sentry のアラートも管理しやすくなります。
フィーチャーフラグ(LaunchDarkly)
前述のOpenFeature SDKをこのLaunchDarklyで管理して、フィーチャフラグを実現します。
LaunchDarkly
LaunchDarklyはフィーチャーフラグ管理のための SaaS で前述のOpenFeatureに対応しています。
LaunchDarkly と Grafana の統合
LunchDarkly には Grafana との統合が用意されており、こちらを利用することでフィーチャーフラグの変更を Grafana ダッシュボードの注釈として表示できます。
「Four Keys」の 4 つの指標のうち、変更失敗率を把握するためにも有用です。
Slack で ChatOps を実現
アラートは基本的に全てSlackに送信して、ChatOps を実現します。
ChatOps
ChatOpsとは運用に関わる様々なタスクを、Slack 等のチャットツールを使用して効率化することで、SaaS との連携による業務効率化、自動化、情報収集の容易化を実現できます。
主なメリットとして、インタラクティブな操作による運用が行える事や、通知の迅速な対応、共有と記録の容易さがあげられます。
DevOps の文化を育むためにも、ChatOps は非常に重要です。
DevOps のツールに正解はない
「DevOps は”文化”」でも紹介したように、ツールは文化を加速させるためのものです。あくまでもツールは手段であり、目的ではありません。
また、 DevOps のツールに正解はありません。「Effective DevOps」ではツールの誤解として、下記を挙げています。
技術Xから、他社に合わせて技術 Y に移行しなければいけない
→ 技術の変更にはコストがかかります。
技術Xを使っているので、うちは devops を実践している
→ DevOps に役立つツールや技術は確かにありますが、それらのツールや技術がなぜ役に立つのかを理解するのが大切です。
間違ったツールを選ばないように注意しなければならない
→ 間違ったツールを選んだからといって失敗する訳ではありません。
DevOps ツール全部入りセットや devops-as-a-Service を購入すればよい
→ 最新の素晴らしい DevOps のツールを持っているだけでは不十分で、成功するにはツールを効果的に使わなければなりません。
DevOps 実現構成というタイトルにしましたが、今回紹介した SaaS を採用したからといって DevOps が成功するわけではありません。
現在の組織に合った適切なツールを選択して、使用するツールや技術についてしっかりと理解し、効果的に活用する事が重要なのです。
さいごに
今回は DevOps についてと様々なツールを紹介しました。
こちらはあくまでも 2024 年 3 月時点での構成なので、今後もどんどん更新していく(もしくは新しい記事を作成する)予定です。また、今回の構成に関連する記事も書いていこうと思うので、そちらもお読みいただければ幸いです！
書籍紹介
今回の記事で登場した書籍です。
- The DevOps 逆転だ！究極の継続的デリバリー
- The DevOps ハンドブック 理論・原則・実践のすべて
- Lean と DevOps の科学
- Effective DevOps
- システム運用アンチパターン
- ソフトウェアアーキテクチャメトリクス
下記書籍も大変参考になります。
記事紹介
今回紹介したサービスについてより詳しく知りたい方は下記の記事をご覧ください。
-
GitHub Actions
-
Prometheus
-
Grafana Loki
-
Grafana k6
-
Snyk
-
CodeRabbit
-
Qase
-
Playwright
-
Sentry
-
LaunchDarkly
また、今回の構成に関連した記事をいくつか書いているので、そちらもご覧いただければ幸いです。
- GitHub Actions のログを Grafana Loki に送信するアクションを作成した
- 外形監視と E2E テストができる Checkly とは？
- Grafana のダッシュボードを Slack に投稿する（メールの画像を Slack に投稿する）(近日公開)
- アラートの管理に便利な「Grafana OnCall」を使ってみよう(近日公開)
Discussion