自分の環境に合わせた DevOps のモニタリング環境を手に入れる方法
光吉 隆雄 (監修 : 山澤 良介)
皆さん、こんにちは。ソリューションアーキテクトの光吉隆雄です。
皆さんは「AWS ソリューションライブラリ」というページがあるのをご存知でしょうか ? この AWS ソリューションライブラリの中には、すぐにお客様の課題に対応できるよう導入までの手順や AWS CloudFormation のテンプレート等を含めた AWS ソリューション実装 というリファレンスとなる実装パターンが多数掲載されています。ただ、この AWS ソリューション実装はリファレンスであるため、実際の皆さんが抱えている環境にそのまま 100% 合致するような実装かと問われると、そうでない場合もあるでしょう。
このソリューション実装は AWS CloudFormation のテンプレートを利用して構築されています。つまり、 Infrastructure as Code の概念で実装されているため、そのコードを変更することによって皆さんの手でカスタマイズすることが可能なのです。今回は AWS DevOps Monitoring Dashboard という AWS ソリューション実装を使って、実際の環境に実装を合わせるためにどのような手順を踏むのかを順を追って説明いたします。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
この記事のデモを無料でお試しいただけます »
毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。
AWS DevOps Monitoring Dashboard とは
AWS DevOps Monitoring Dashboard とは継続的インテグレーション / 継続的デリバリー (CI/CD) を行う上で各 CI/CD ツールがバラバラに出力したメトリクスを一箇所に取り込み、それを分析し、可視化するまでのプロセスを自動化するリファレンス実装となります。
これによって、たとえばどのプロジェクトやチームでどの程度デプロイやアクティビティがあったのか、各プロジェクトやチームのシステムの安定度はどの程度なのか、といった情報を定量的なメトリクスで横串で可視化できます。
結果、これを利用することで DevOps の管理者や開発・運用のリーダーの改善に向けた意思決定をデータに基づくものにします。
なお、AWS DevOps Monitoring Dashboard に関するさらに詳細な使い方や具体的な説明は「AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法」というブログ記事に細かく記載しておりますのでそちらをご覧ください。
要件にマッチしない・・・でもちょっと待って !
さて、それでは皆さんのチームやプロジェクトで AWS DevOps Monitoring Dashboard が有用そうであると感じたとしましょう。ただ、ここで問題が発生します。CI/CD のツールは AWS が提供しているもの以外にもたくさんあります。皆さんの中には AWS CodeCommit ではなく GitHub を利用されている方もいらっしゃるでしょうし、AWS CodePipeline や AWS CodeBuild ではなく Jenkins を利用されている方もいらっしゃるでしょう。CI/CD ツールはプロジェクトやチームによって統一されておらず、バラバラであるかもしれません。しかし AWS DevOps Monitoring Dashboard は AWS CodeCommit や AWS CodeBuild、AWS CodeDeploy、そして AWS CodePipeline にのみ対応しているリファレンス実装となっているため、そのまま利用することはできません。
ただちょっと待ってください。AWS DevOps Monitoring Dashboard はリファレンス実装です。そしてこのリファレンス実装は AWS CDK や AWS CloudFormation によって作られています。そのままでは実際の現場のニーズを満たさない場合でも、コードを修正することによって、もしくはサービスの設定を追加・修正することによって皆さん自身の手で内容をカスタマイズすることができるのです。そしてそれこそが AWS ソリューション実装の魅力であると言えるでしょう。
今回は皆さんのチームが GitHub リポジトリを活用しているプロジェクトであると仮定し、GitHub Organization に属するリポジトリの開発状況を 1 つのダッシュボードで確認したいという目標のために AWS DevOps Monitoring Dashboard をどのようにカスタマイズしていくか見ていきましょう。
なお、2022 年 4 月 19 日には AWS DevOps Monitoring Dashboard に新機能として GitHub との連携が実装されました。後述でも繰り返しますが、単純に Github と連携したい場合は AWS ソリューション本体に実装されている機能を利用することを推奨します。
ソリューションの構造を理解する
ソリューションをデプロイする
ソリューションの具体的なデプロイ方法は「AWS DevOps Monitoring Dashboard ソリューションを使用して CI/CD メトリクスのキャプチャと分析を自動化する方法」に記載しているのでそちらに沿ってデプロイを行ってください。
ただし、今回の目的に沿ってデプロイするための注意点が 2 点あります。デプロイのパラメータとして設定する Amazon QuickSight Principal ARN と AWS CodeCommit Repository List についてです。Amazon QuickSight Principal ARN は Amazon QuickSight での可視化の際に必須となるため必ず事前に Amazon QuickSight の Enterprise 版をサブスクライブして ARN を入手してください。また、AWS CodeCommit Repository List については、Github 上の複数のリポジトリ情報を確認したいという目的があるためデフォルト値の ‘ALL’ のままでデプロイしてください。
ソリューションを読み解く
では、実際に GitHub リポジトリのイベントを追加するようなカスタマイズできるかについて、手を動かす前に AWS DevOps Monitoring Dashboard 自体をより理解することから始めてみましょう。
今回はソース管理サービスである GitHub リポジトリを追加のターゲットとしているため、AWS CodeCommit からイベントデータがどのように流れているのか、先程の図を参考にひとつづつ見ていきましょう。
AWS CodeCommit はデフォルトで push イベントを Amazon CloudWatch に送信します。そこからその push イベントを Amazon EventBridge でルーティングしているのがわかります。ここがイベントを拾う起点となっているわけです。
それでは Amazon EventBridge ではどのような設定が行われているのでしょうか。AWS Console より Amazon EventBridge のルールの項目を確認してみましょう。そこには「任意の名前-CodeCommitEventsRuleXXXXXX-XXXXXXXX」という名前でルールが作られています。
クリックすると拡大します
この Amazon EventBridge のルールでは、一定間隔や特定の条件に基づいて、マッチしたイベントを指定したターゲットに送信することができます。そして条件についてはイベントパターンで確認できます。
「任意の名前-CodeCommitEventsRuleXXXXXX-XXXXXXXX」では上図のように
- detail-type : AWS API Call via CloudTrail
- source : aws.codecommit
となっており、なおかつ、eventName が指定された 4 つのイベント名のいずれかに合致するイベントであった場合にマッチしたイベントと見做します。そしてマッチしたイベントがターゲットである Amazon Kinesis Data Firehose のストリームに流されるということが見て取れます。
続いて Amazon Kinesis Data Firehose にて行われている処理です。
ここでは渡ってきたイベントを AWS Lambda を使って整形し、欲しい情報だけを抽出してから Amazon S3 にデータをロードしています。Amazon EventBridge のルールに記述されていたターゲット情報などから Amazon Kinesis Data Firehose の設定に移動すると、利用されている AWS Lambda の関数やロード先の Amazon S3 のバケットの情報を確認できます。
クリックすると拡大します
ここから更に AWS Lambda に移動することによってどのような処理されているのかコードベースで確認することができます。
この Lambda 関数では source の値によって取得する情報を切り分けています。つまり、この Lambda 関数で AWS CodeCommit だったらこういう情報、AWS CodeDeploy だったらこういう情報というように、最終的なモニタリング画面で欲しい情報を選別しています。
それでは最後に Amazon S3 に溜まったこれまでの情報を可視化のための情報として整理する Amazon Athena がどのように動いているのか確認してみましょう。
Amazon Athena は Amazon S3 内のデータを 標準 SQL を用いて簡単に分析できるサービスです。本ソリューションでは Amazon Athena のビュー作成をデイリーで行っており、そのビューを Amazon QuickSight が参照することで可視化を行えるようになっています。
このビュー作成は Amazon EventBridge のルールによるスケジュールと AWS Lambda が担っています。具体的には「任意の名前-AddAthenaPartitionLambdaFunctionXXXXXXXXX」という Lambda 関数によって実装されており、下記に示すのがその一部分となります。
let BuildCodeChangeActivityQuery = (athenaDB, athenaTable, includedRepositoryList, dataDuration) => {
LOGGER.log('INFO', '[BuildCodeChangeActivityQuery] Start');
let queryString =
'CREATE OR REPLACE VIEW ' + athenaDB + '.code_change_activity_view AS ' + '\n' +
'SELECT account, time, region, ' + '\n' +
'detail.eventName as event_name, ' + '\n' +
'detail.repositoryName as repository_name, ' + '\n' +
'detail.branchName as branch_name, ' + '\n' +
'detail.authorName as author_name, ' + '\n' +
'detail.commitId as commit_id, ' + '\n' +
'created_at' + '\n' +
'FROM' + '\n' +
athenaDB + '.' + athenaTable + '\n' +
"WHERE source = 'aws.codecommit'"
const dataDurationQueryString = BuildDataDurationQuery(dataDuration);
queryString = queryString + '\nAND ' + dataDurationQueryString
// add filter by customer selected repos if configured
if (includedRepositoryList.length > 0 && includedRepositoryList !== "'ALL'")
queryString = queryString + '\nAND detail.repositoryName in (' + includedRepositoryList + ');'
else queryString = queryString + ';';
LOGGER.log('INFO', 'Query string: \n'+ queryString);
LOGGER.log('INFO', '[BuildCodeChangeActivityQuery] END');
return queryString;
};これは code_change_activity_view というビューを作成または再作成するクエリを作っている関数です。ここで作成されたクエリを Amazon Athena が実行することでビューが作られるようになります。
標準的な SQL であるビューと同じ考え方になりますが、もう少し丁寧に見ていきましょう。
'CREATE OR REPLACE VIEW ' + athenaDB + '.code_change_activity_view AS ' + '\n' +上記の部分はビューの作成を宣言している部分で code_change_activity_view という名前のビューを作成いようとしています。そして、もし既にビューが存在する場合は新しく作成して置き換えるように CREATE OR REPLACE VIEW となっていいます。
'SELECT account, time, region, ' + '\n' +
'detail.eventName as event_name, ' + '\n' +
'detail.repositoryName as repository_name, ' + '\n' +
'detail.branchName as branch_name, ' + '\n' +
'detail.authorName as author_name, ' + '\n' +
'detail.commitId as commit_id, ' + '\n' +
'created_at' + '\n' +
'FROM' + '\n' +
athenaDB + '.' + athenaTable + '\n' +続いてそのビューに入る情報を指定している部分になります。account や time、region はAmazon EventBridge による基本的なイベント情報です。eventName は Amazon EventBridge のルールの条件に指定されていた部分で、それ以降は AWS CodeCommit のコミットにまつわる情報となります。
"WHERE source = 'aws.codecommit'"最後に注目してほしい箇所はここです。Amazon S3 には もともと AWS CodeCommit 以外にもAWS CodeDeploy や AWS CodePipeline といった様々なイベントが保存されるようになっています。このままだとそういった部分も全て含まれたビューとなってしまうので WHERE 句でイベントの発生元を示す source で条件付しています。
GitHub リポジトリのメトリクスを取る方法を検討する
ソリューションの流れは理解できました。それでは次は GitHub のリポジトリに対する push した情報を AWS 側に送信する方法を考えてみましょう。この push イベントを受け取るにはいくつか手段があります。
1 つ目は GitHub の webhook を活用し、push イベント発生時に Amazon API Gateway に push イベントを送信し、Amazon EventBridge に繋げる方法です。2 つ目は GitHub の GitHub Actions を活用し、同じく push イベント発生時に Amazon EventBridge に AWS CLI 経由で push イベントを送信する方法です。3 つ目は 2 つ目と同じく GitHub Actions を活用し、push イベントを Amazon EventBridge ではなく AWS CodeCommit にミラーリングすることで AWS CodeCommit の push イベントの発生させるという方法です。
1 つ目は Amazon API Gateway というサービスが挟まることで手順が増えてしまいますし、セキュリティの考慮や認証認可の設定などを検討をしないといけないといません。3 つ目もミラーリングするための AWS CodeCommit を追加しなければいけない点と、対象となる GitHub リポジトリが増えるごとに AWS CodeCommit にもそれに対応したリポジトリを追加しないといけないという作業が発生します。
これらに対して 2 つ目の Amazon EventBridge に通知する手法は、先程見てきた本ソリューションの流れに添うものとなっています。そのため今回は 2 つ目に記載した GitHub Actions から Amazon EventBridge に push イベントを通知する手法で AWS DevOps Monitoring Dashboard をカスタマイズしていくことにします。
なお、今回はこのような手法を選択しましたが、プロジェクトやチームの状況により条件や検討する手法は変わります。そのため今回の実装が必ず正しいというわけではなく、あくまで AWS ソリューション実装のカスタマイズを行う流れの一例としてご承知ください。
また、先述しましたとおり 2022 年 4 月 19 日には、AWS DevOps Monitoring Dashboard に新機能として GitHub との連携が実装されました。ソリューション本体では Github との連携に webhook を利用しています。そのため webhook を利用したくないような場合を除き、GitHub と連携する場合はソリューションの機能をそのまま利用することを推奨いたします。以降は Github Actions を利用した場合の実装の参考としてください。
GitHub Actions を設定する
AWS CLI認証
まずは GitHub Actions で AWS CLI を実行できる環境を整えましょう。
これまで GitHub Actions では、クレデンシャルを発行し GitHub に登録する必要があったため、発行したクレデンシャルの管理をどうするかなどの課題がありました。しかし、2021 年に GitHub Actions が OpenID Connect に対応したことにより、クレデンシャルを発行せずにGitHub に一時的なAWS へのアクセス権を与えることができるようになりました。今回はこの仕組を利用します。
なお、本記事は執筆段階でのもので、あくまでリファレンスとしての記載ですので、実際にこれらを設定する際は各種公式ドキュメントを確認して実装を行ってください。
それではこの仕組を利用するために、まずは ID プロバイダを使用した IAM Role を作成しましょう。
AWS Console からは まず AWS IAM のページに移動し、「ロール」から「ロールを作成」を選択します。そうすると「信頼されたエンティティを選択」という画面に遷移します。ここではウェブアイデンティティを選択、下部に出現したアイデンティティプロバイダーで「新規作成」を選択します。
クリックすると拡大します
ID プロバイダの作成画面では GitHub の OpenID Connect と連携するための設定を行います。「Open ID Connect」を選択しプロバイダの URL と対象者に下記を入力しましょう。そして「サムプリントを確認」をクリックしプロバイダ側の証明書を確認します。最後に下部の「プロバイダの追加」をクリックすることで ID プロバイダの作成は完了です。
- プロバイダの URL : https://token.actions.githubusercontent.com
- 対象者 : sts.amazonaws.com
クリックすると拡大します
IAM Role 作成画面に戻って作ったばかりの ID プロバイダと Audience を選択しましょう。
もし作成した ID プロバイダが選択肢に含まれていない場合は「新規作成」ボタンの左にある更新ボタンをクリックしてから確認してみましょう。問題なければ「次に」をクリックし「許可を追加」の画面に遷移します。
この画面ではこの IAM Role にどのような権限を渡すかを設定できます。今回は GitHub Actions から Amazon EventBridge にイベントを送信することを目的としているため専用のポリシーを作成することにしましょう。「ポリシーの作成」をクリックします。
クリックすると拡大します
ポリシーの作成画面ではどのサービスに対してどのようなアクションをどのようなリソースに許可するのかを設定することができます。今回は Amazon EventBridge にイベントを送信する許可が欲しいため、それらの設定を追加します。
- サービス : EventBridge
- アクション : PutEvents
- リソース : 「指定」して event-bus をソリューションを読み解く過程で確認した「任意の名前-CodeCommitEventsRuleXXXXXX-XXXXXXXX」のイベントバスの ARN にする。
クリックすると拡大します
問題なければ「次のステップ: XX」をクリックしていき任意のポリシーの名前を入力して「ポリシーの作成」をクリックですることでポリシーの作成は終了です。
ID プロバイダのときと同じく作成したポリシーを「許可を追加」する画面でチェックし、「次へ」をクリックしてください。
最後に任意のロール名を入力して「ロールを作成」をクリックすることでロールが作成されます。以下に各画面のスクリーンショットを示しますので参考にしてください。
「次のステップ : 確認」をクリック。
クリックすると拡大します
名前を入力して「ポリシーの作成」をクリック。
クリックすると拡大します
「許可を追加」画面に戻り作成したポリシーを検索してチェックを入れ「次へ」をクリック。
クリックすると拡大します
ロール名を入力して「ロールを作成」をクリック。
クリックすると拡大します
最後に作成したロールの信頼ポリシーを編集します。このままだと ID プロバイダで認証された GitHub からの認証情報を Audience (ID プロバイダを作成した際に入力した対象者のこと) のみで信頼してしまうからです。そのため特定の Organization に属するリポジトリからの認証のみ信頼するように設定を変更します。
前の手順で作成したロール名で検索してロールの詳細画面に遷移し、信頼関係タブをクリックし、「信頼ポリシーを編集」ボタンをクリックすることで信頼ポリシーを編集できます。ここでたとえば下記のように設定することで「octo-org」という Organization に属するリポジトリのみを対象とするように設定できます。問題なければ「ポリシーを更新」をクリックして設定完了です。
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:octo-org/*"
}
}
クリックすると拡大します
Amazon EventBridge に送信
認証の設定が終わったので、次は GitHub から push イベントを送信してみましょう。GitHub Actions では AWS の認証情報をセットする「configure-aws-credentials」という action を AWS 公式で用意しています。そのため、この action を利用して GitHub Actions の workflow を作成していきましょう。
name: put-push-event
on: push
permissions:
id-token: write
jobs:
put-push-event-to-eventbridge:
runs-on: ubuntu-latest
steps:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
role-to-assume: arn:aws:iam::XXXXXXXXXX:role/GitHubActionsRole
aws-region: ap-northeast-1
- name: Put Event
run: |
aws events put-events \
--entries '[{"Source": "github.repo", "Resources": [], "DetailType": "AWS API Call via GitHubActions", "Detail": "{\"eventName\":\"GitPush\", \"authorName\":\"${{github.actor}}\", \"repositoryName\":\"${{github.repository}}\", \"branchName\":\"${{github.ref}}\", \"commitId\":\"${{github.sha}}\"}" }]'workflow の記述仕様について詳細は省きますが上記のような形となります。
on は今回は push イベントに応じてイベントを送信したいため push のみです。ポイントは permissions に id-token: write を記載している点です。これによって GitHub の OIDC プロバイダから JWT をリクエストできるようになります。あとは先述した「configure-aws-credentials」を使用して必要なパラメータである AssumeRole 用の ARN と利用するリージョンを記述します。
次は実際に Amazon EventBridge に push イベントを送信してみましょう。ubuntu-latest には既に AWS CLI がインストールされているため AWS CLI コマンドを実行するだけでイベント送信できます。具体的には aws events put-events を利用します。イベントの定義は JSON 構造になっており、イベントの送信元を示す Source、イベントの概要を示す DetailsType、そしてイベントの具体的内容を Detail で定義します。Source や DetailsType は、「AWS が受信した情報を利用する」セクションに登場する Amazon EventBridge でのフィルターとして利用するため、正確な文字列を定義してください。
また、Detail は実際のイベントデータとなるため、必要な情報が記述されているか確認しておきましょう。put-events にはその他にも設定できる項目があります。詳細は AWS CLI Command Reference を御覧ください。
AWS が受信した情報を利用する
ソリューションの構造を一通り理解し、GitHub Actions から Amazon EventBridge に push イベントを送信することもできました。それでは次は渡ってきたイベントをつなげて、Amazon QuickSight に情報が渡るように設定していきましょう。
Amazon EventBridge
まずは push イベントを受け取った Amazon EventBridge の部分です。この部分ではルールを設定することにより、特定のイベントを拾いあげて指定したターゲットにイベントを送信していました。ということは、このルールに GitHub Actions で定義した entries の構造を足してあげればよいわけです。
{
"detail-type": ["AWS API Call via CloudTrail", "AWS API Call via GitHubActions"],
"source": ["aws.codecommit", "github.repo"],
"detail": {
"eventName": ["PutFile", "DeleteFile", "UpdateFile", "GitPush"]
}
}上記はイベントパターンのサンプルです。detail-type に “AWS API Call via GitHubActions” を、source に “github.repo” を追加しています。これによって GitHub Actions から呼び出した AWS CLI によるイベントをこのルールが拾うことになります。
Amazon Kinesis Data Firehose の Lambda 関数
続いてイベントを変形させて必要な情報を集約させる Lambda 関数のカスタマイズです。この部分では index.js の exports.handler から Lambda 関数の処理がスタートし、 source ごとにそれぞれの専用モジュールを利用してパース処理を実行しています。
それではGitHub リポジトリからのイベントも AWS CodeCommit のイベントを参考に作成してみましょう。ここで取り扱っている構造は GitHub Actions で --entries で定義したイベントの構造と対になっていることに気をつけて実装しましょう。下記は簡単な例となります。
'use strict';
const LOGGER = new (require('./lib/logger'))();
let TransformGithubEvents = (data, recordNumber) => {
LOGGER.log('INFO', 'Start transforming github Event ' + recordNumber.toString());
let detailData = {};
let requestParametersData = {};
let responseElementsData = {};
let transformedRecord = {};
let transformedDetail ={};
for(var key in data){
if (key != 'detail') {
if (!transformedRecord.hasOwnProperty(key)){
if (key != 'detail-type') transformedRecord[key] = data[key]
else transformedRecord['detail_type'] = data[key]
}
}
else{
detailData = data["detail"];
if (detailData.hasOwnProperty("eventName"))
transformedDetail["eventName"] = detailData["eventName"]
if (detailData.hasOwnProperty("authorName"))
transformedDetail["authorName"] = detailData["authorName"]
if (detailData.hasOwnProperty("repositoryName"))
transformedDetail["repositoryName"] = detailData["repositoryName"]
if (detailData.hasOwnProperty("branchName"))
transformedDetail["branchName"] = detailData["branchName"]
if (detailData.hasOwnProperty("commitId"))
transformedDetail["commitId"] = detailData["commitId"]
}
}
transformedRecord['detail'] = transformedDetail
LOGGER.log('DEBUG', 'Transformed record: ' + JSON.stringify(transformedRecord, null, 2));
LOGGER.log('INFO', 'End transforming github Event ' + recordNumber.toString());
return transformedRecord;
};
module.exports = {
transformGithubEvents: TransformGithubEvents
}モジュールを作成したら index.js でそのモジュールを読み込ませ、他のイベントと同様に GitHub Actions から渡ってきたデータに対してパースを実行するように処理を追加しましょう。これらの修正を保存しデプロイすることで、これ移行の GitHub リポジトリの push データは Amazon S3 に格納されるようになります。
const githubEvents = require('./github_events'); // 追加
const codeCommitEvents = require('./codecommit_events');
・
・
・
// 追加: Transform GitHub events data
if (parsedData['source'] == 'github.repo') {
transformedRecord = githubEvents.transformGithubEvents(parsedData, recordCount);
}
// Transform codecommit cloudwatch events data
if (parsedData['source'] == 'aws.codecommit') {
transformedRecord = codeCommitEvents.transformCodeCommitEvents(parsedData, recordCount);
}Amazon Athena のビュー作成
最後に格納された Amazon S3 のデータを可視化するためのクエリ処理に GitHub リポジトリの push イベントを追加します。Amazon Athena は Lambda 関数によってビューの作成処理が実装されていたので、その部分を修正します。先述と同じように source に対して 'github.repo' を条件として追加するだけです。修正が完了したらこちらも保存しデプロイすることで、次回実行以降で本変更が反映されます。
なおビューの更新はデイリーで行っているため、すぐに反映された結果を確認することはできません。すぐに確認したい場合はご自身の手で本 Lambda 関数を実行することですぐに反映させることができます。
let BuildCodeChangeActivityQuery = (athenaDB, athenaTable, includedRepositoryList, dataDuration) => {
LOGGER.log('INFO', '[BuildCodeChangeActivityQuery] Start');
let queryString =
'CREATE OR REPLACE VIEW ' + athenaDB + '.code_change_activity_view AS ' + '\n' +
'SELECT account, time, region, ' + '\n' +
'detail.eventName as event_name, ' + '\n' +
'detail.repositoryName as repository_name, ' + '\n' +
'detail.branchName as branch_name, ' + '\n' +
'detail.authorName as author_name, ' + '\n' +
'detail.commitId as commit_id, ' + '\n' +
'created_at' + '\n' +
'FROM' + '\n' +
athenaDB + '.' + athenaTable + '\n' +
"WHERE source IN ('aws.codecommit', 'github.repo')" // 変更
const dataDurationQueryString = BuildDataDurationQuery(dataDuration);
queryString = queryString + '\nAND ' + dataDurationQueryString
// add filter by customer selected repos if configured
if (includedRepositoryList.length > 0 && includedRepositoryList !== "'ALL'")
queryString = queryString + '\nAND detail.repositoryName in (' + includedRepositoryList + ');'
else queryString = queryString + ';';
LOGGER.log('INFO', 'Query string: \n'+ queryString);
LOGGER.log('INFO', '[BuildCodeChangeActivityQuery] END');
return queryString;
};可視化を試してみよう
以上でカスタマイズは終了です。それではこれらが正しく反映されているか Amazon QuickSight を確認してみましょう。GitHub の対象となる Organization の中のリポジトリで push イベントを発行し、 Amazon Athena のビューが更新されたことを確認してから Amazon QuickSight の Dashboard を開いてみましょう。Author や リポジトリ名は伏せさせていただきましたが、複数のリポジトリおよび Author が同じ Dashboard 上でグラフ化されて表示されていることが確認できます。
AWS CDKに反映する
ここまで AWS ソリューション実装から AWS CloudFormation でソリューションを構築しカスタマイズするまでを見てきました。しかし、カスタマイズしたものを Infrastructure as Code として残しておきたい場合もあるでしょう。
AWS DevOps Monitoring Dashboard の公式ページでは「ソースコード」というリンクを用意しており、GitHub 上で本ソリューションを AWS CDK として公開しています。そのため、このリポジトリを fork してご自身の手で様々なカスタマイズを施すことが可能となっています。
たとえば今回のようなカスタマイズの場合は、Lambda 関数の実装や Amazon EventBridge のルール作成部分を検索すれば修正すべき場所がすぐに見つかります。あとは AWS IAM の ID プロバイダの追加と IAM Role を作成する処理を追加することで、上述してきたカスタマイズの構成をコードで表現できます。
まとめ
AWS ソリューション実装をカスタマイズするために、その実装の構成を理解し、追加したい機能に必要な構成を検討し、それを実装していくまでの流れを実践してみました。
最初に説明したとおり、AWS ソリューション実装はリファレンス実装です。そしてその実装は GitHub リポジトリに公開されています。まったくのゼロからこういったソリューションを自らの手で構築するのは、様々なことを検討しなければならず、また多くの AWS サービスを理解していないと難しい面もあります。しかし、AWS ソリューション実装をひとつのリファレンスとして捉えることで、AWS ソリューション実装をより効果的に利用できるようになるのではないでしょうか。
本記事が AWS をより効果的に利用できるきっかけとなれば幸いです。
筆者プロフィール
光吉 隆雄
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 西日本ソリューション部 ソリューションアーキテクト
ソリューションアーキテクトとして、西日本や関西のお客様を支援させていただいております。前職では DevOps や CI/CD ツールの導入を担当し、AWS CodeBuild や AWS App Runner に関心があります。
趣味で脱出ゲームやアナログゲームの作成や DTP デザインをしています。
監修者プロフィール
山澤 良介
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
テクニカルソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。
前職では主にネットワーク案件を担当していたため、好きなサービスは、AWS Direct Connect と AWS Transit Gateway です。
休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っているほか、オフシーズン中もオフトレ施設に行っています。
AWS を無料でお試しいただけます