2024-08-10

AWSでVPNサーバを構築してPTCGLをプレイする

AWS

みなさん VPN が必要になったことはありませんか。最近はリモートワークも増え、セキュリティなどの関係で導入する企業が増えているのではないでしょうか。

セキュリティとは無関係にとにかく VPN が必要な場合もあります。例えば、海外のオンラインゲームをプレイするときなど... ゲームによっては日本国内からのアクセスを制限していることがあり、VPN を利用して海外からのアクセスに見せかけてあげる必要があります。

自分がはまっているゲーム PTCGL もその 1 つ。Pokémon Trading Card Game Live を略して PTCGL、オンラインでポケモンカードができるゲームです。ポケモンといえば発祥は日本のはずですが、なぜかこのゲームは日本からアクセスできません。プレイするためには VPN が必要です。不思議です...

https://tcg.pokemon.com/en-us/tcgl/

様々な VPN サービスはあれど、快適にお安く使えるものはなかなかありません。そこでクラウドサービスの AWS を使って任意の国に自分専用の VPN サーバを建ててみます。

概要
- 費用
- SoftEther VPN
構築手順
- 事前準備
- CloudFormationスタックの作成
VPN接続
- iPad から接続
環境の削除手順
まとめ
Tips
- EC2インスタンスに入って設定を変更したい

概要

本ブログでは AWS 上に SoftEther を利用した VPN サーバの構築手順を紹介します。画面上で必要なパラメータを入力し、AWS に適用することで手軽に VPN サーバを建てることができます。

VPN へ誰でも接続できる状態になってしまうことを避けるため、アクセス元を特定の IP、今回であれば自宅などのネットワークからのアクセスのみに絞っています。

費用

この VPN サーバを構築すると AWS の利用料金がかかります。 1 日あたりの費用は 0.3 USD ほどで、月に 10 USD ほどかかる計算です。ただし AWS で構築した VPN はいつでも手軽に削除できるので、使わないときは削除してしまえば費用はかかりません。

SoftEther VPN

本 VPN は筑波大学の研究プロジェクトとして運営されているオープンソース VPN ソフトウェアの SoftEther VPN を利用させて頂いています。開発してくださった登様及び関係者の皆様に感謝申し上げます。

ja.softether.org

構築手順

事前準備

AWS アカウントの作成
- https://aws.amazon.com/jp/register-flow/ を参照
CloudFormation テンプレートのダウンロード
- 以下のテンプレートをダウンロードまたはコピーして aws-vpn.yaml として保存
  - リンク: https://gist.github.com/itiB/aws-vpn.yaml
  - コード内容: aws-vpn.yaml
自宅のグローバル IP アドレスを確認
- PTCGL をプレイする端末で https://www.cman.jp/network/support/go_access.cgi などにアクセスし、確認してください
- 表示された IP アドレスをメモしておいてください

CloudFormationスタックの作成

CloudFormation は AWS のサービスの 1 つで、AWS リソースをテンプレートで定義し、一括で作成・更新・削除ができるサービスです。今回は事前準備にてダウンロードした aws-vpn.yaml のテンプレートを使用します。VPN を作成するために必要なリソースが定義されています。

CloudFormation コンソールへアクセス
リージョンを選択
- 画面右上のリージョン選択ボタンから 米国東部（バージニア北部） を選択
「スタックの作成」より「新しいリソースを使用（標準）」を選択
「テンプレートの指定」欄で「テンプレートファイルのアップロード」を選択し、事前準備で用意した aws-vpn.yaml をアップロード、「次へ」

「スタックの詳細を指定」にて以下を設定し、「次へ」

すでに埋まっているパラメータはそのままで問題ありません

パラメータ名	入力内容	備考
スタック名	<任意の名前>	e.g. `aws-vpn`
MyHomeIp	事前準備でメモした自宅のIPアドレスを入力	このアドレスからのみVPNを使えるようになります
SoftEtherAdminPassword	<任意のパスワード>	基本的に使うことはないです。VPN の設定を変更する際に使われます。
SoftEtherHubPassword	<任意のパスワード>	基本的に使うことはないです。VPN の設定を変更する際に使われます。
VPNUserName	<任意のユーザ名>	VPN接続時に使用するユーザ名
VPNUserPassword	<任意のパスワード>	VPN接続時に使用するパスワード

「スタックオプションの指定」はそのまま「次へ」
「確認して作成」画面はパラメータがすべて入力されているかを確認し、「スタックの作成」をクリック
スタックが完成するまで待つ
- 以下の画面に遷移し、スタックの作成が開始されます
- しばらく待つと設定した論理IDに設定したスタック名、ステータスに CREATE_COMPLETE と表示され、作成が完了します
VPN サーバの情報を確認
- スタックの詳細画面にある「出力」タブをクリック
- EIPPublicIp に表示されている IP アドレスが VPN サーバの IP アドレスです
- VPNAccessName に表示されている名前で VPN に接続できます

VPN接続

普段使っているデバイスから VPN サーバに接続してみましょう。例として普段自分が利用している iPad から接続する例を紹介します。

iPad から接続

設定 → VPN → VPN 構成を追加... で以下の情報を入力。

項目	入力内容
タイプ	L2TP
説明	<任意の名前>
サーバ	CloudFormation の出力タブにある `EIPPublicIp` の値
アカウント	CloudFormation の出力タブにある `VPNAccessName` の値
RSA SecureID	オフ
パスワード	`VPNUserPassword` に入れた値
シークレット	`aws-vpn-psk` ※CloudFormationのパラメータで `VPNPreSharedKey` の値を書き換えた場合はその値
すべての信号を送信	オン
プロキシ	オフ

完了ボタンを押したのちに接続ボタンを押し、PTCGL を起動してプレイできることを確認しましょう。

環境の削除手順

VPN サーバを使わなくなった場合は作成した CloudFormation スタックを削除してください。 aws-vpn のスタックを削除することで VPN サーバが削除され、費用の発生を抑えることができます。

まとめ

無事に接続できたでしょうか。今回は家のグローバル IP アドレスからのみ接続できるように設定しましたが、この IP アドレスは不定期に変わる可能性があります。もしつながらなくなった際には IP アドレスを調べなおして CloudFormation のスタックを削除、作り直してください。

もし何かわからない、つながらない等あればお気軽にご連絡ください。よい PTCGL ライフを👍

Tips

EC2インスタンスに入って設定を変更したい

CloudFormation の SecurityGroupPublic でコメントアウトされている 22 番ポートを開ける設定を有効にする
CloudFormation の更新
pem の取得
- CloudFormation の出力タブにある KeyPairUrl にアクセス
- 値の欄に記載されている文字列（トグルボタンをクリックすると表示される）をコピーして、任意の場所に aws-vpn-key.pem という名前で保存
キーの権限を変更
- chmod 400 aws-vpn-key.pem
SSH 接続
- ssh -i aws-vpn-key.pem ec2-user@ec2-54-86-25-202.compute-1.amazonaws.com
SoftEther は /usr/local/vpnserver に配置されています

SoftEther の詳細な操作方法は公式ドキュメントを参照してください。

2024-06-23

AWS Summit 2024 の聴講メモ

AWS

AWS Summit 2024 が 6 月 20 日、21 日にかけて開催されたので、参加してきました。多岐にわたるセッションに参加し、多くの学びを得ることができたので、その内容をまとめます。

聴講したセッションの中でも特に自分の学びになったと感じたセッションは以下でした。

AWS-01 Dive deep on Amazon S3
- S3 の効率的な利用方法について具体的な知識が得られた
AWS-28 大規模クラウドインフラ設計、構築案件の歩き方
- 大規模インフラの設計と構築における課題を具体化し、対応のために実践的な進め方と方針を示していただいた
AWS-57 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法
- インフラは見ていたけどアプリケーション自体がどう区切られているのか自身があまり理解できていなかったところに分割方法や考え方を教えてくれた
AWS-59 アーキテクチャ道場 2024！
- 発想を毎年広げてくれるのでお勧め

このブログではアーキテクチャ道場を除く3つのセッションについてメモした内容と感想をまとめます。個人的にとっていたメモを整理したものなので、セッションの内容と少しずれている可能性もあります。

詳細な内容は AWS Summit 2024 の公式サイト上から資料をダウンロード、配信をみることができるのでぜひご活用ください。

aws.amazon.com

AWS-01 Dive deep on Amazon S3

公式概要

Amazon S3 は、業界トップクラスのスケーラビリティ、耐久性、セキュリティ、パフォーマンスを提供するクラウドオブジェクトストレージです。このセッションでは、Amazon S3 の基盤となるアーキテクチャを掘り下げ、どのようにしてスケーリングと伸縮自在性を実現しているのかを見ていきます。データ保護方法、データの耐久性に対する考え方や文化、そして新しい Amazon S3 Express One Zone ストレージクラスがどのように一貫したパフォーマンスを実現するかについて知っていただき、利用者の機械学習ワークロードや、データ分析を支える仕組みの理解を深めます。

登壇者

焼尾徹様
アマゾンウェブサービスジャパン合同会社
シニアストレージスペシャリストソリューションアーキテクト

内容のメモ

Amazon Simple Storage Service （S3）とは

350 以上のマイクロサービスが組み合わさることで S3 が実現されている。
リアクティブ（問い合わせベースの運用）な運用から脅威モデリング（事例ベースで運用を共有）をベースにした運用、プロアクティブ（予測して事前に改善していく）と変遷してきたサービス。
フロントエンド、インデックス層、ストレージ層に分かれておりそれぞれに工夫がなされている。

フロントエンドの理解

1PB/秒を超えるピークトラフィックに対応するため、以下の工夫がなされている。

マルチパートアップロード
- 大きなファイルは分割して並列でデータを転送する
- これによってどれかのアップロードに失敗しても全部やり直さなくて済む
- もちろんダウンロードも分割されており、並列でダウンロードされたものが結合され 1 つのオブジェクトに戻っている
DNS で複数の S3 エンドポイントを返す
- 複数のエンドポイントをDNSが返すことで、リクエストが分散され、効率的に処理される

これらは 0 から実装すると大変だが、AWS SDK を使えば勝手にやってくれる。AWS SDK を使うのがよい。

S3 mountpoint について
- 従来 S3 をストレージとしてマウントするのはよくないといわれてた → S3 は HTTP のリクエストベースで動かすことを念頭に作られているから
- mountpoint の実現にあたりマウントに関わる処理を HTTP に変換して実装し、比較的快適に動くところまできた。
- ユースケースとしては機械学習を想定

インデックスの理解

ストレージ層で使われる Key/Value がインデックス。特定のストレージに特定インデックスのオブジェクトが配置されることになる。インデックスにはプレフィックス（バケット名のあとに続く任意の文字列）が用いられており、特定のインデックスへのアクセスが集中した際にはプレフィックスを分割することで負荷を分散させている。

プレフィックスでインデックスを作っているため、以下に留意するとトランザクション/秒（TPS）が向上する

カーディナリティをプレフィックスの左に寄せる
日付はプレフィックスの右側に寄せる
- ex. sample-bucket/prefix/a/day1

ストレージ層の理解

ストレージそうでは以下の工夫で 11 9s（イレブンナイン）の耐久性を実現している。

リクエスト時の整合性チェック
- アップロードのリクエスト時、ストレージ上、あらゆる箇所でチェックサムをとり比較
冗長してデバイスに格納
- デバイスが故障しても他の箇所から復元をし、継続的に冗長性を保つ
- マルチ AZ でデータを保存し、AZ 障害が発生してもデータを復元できる
定期的に耐久性を監査
- チェックサムを定期的に検査

Amazon S3 Express One Zone ストレージクラス

Express One Zone も整合性チェックや冗長して保存、耐久性の監査を通じて 11 9s の耐久性を持つが、マルチ AZ ではなく単一 AZ に保存される性能重視のストレージクラス。つまり AZ 障害でデータを失う可能性はある。

なぜこのようなストレージクラスが作られたのか
- 中のオブジェクトを利用するアプリケーションと同一の AZ に配置することで I/O 性能が上がる
- リクエストにおける CreateSession も最初のみにしてパフォーマンスを上げる
用途の例
- 機械学習における「トレーニング」
  - I/O スループットがボトルネックやトレーニングの時間増加につながる問題を解決する

誤削除への対策

人間が間違えて消してしまうとどうしよもない。以下の対策が存在。

S3 Versioning
S3 Replication
S3 Object Lock
Backups

感想

すぐに活用できる例として S3 のプレフィックスの話は非常に有用だと感じた。裏側がわかるとうまくツールを扱えるようになる例だなと感じる。機械学習のデータセットを保存する際には Express One Zone が使えるというのも知識として持っておくとよいと感じた。

セッションの中では S3 というのがいかに大きなトラフィックを捌いているか、また様々な工夫がされていることを知ることができた。その工夫に乗るためには以下を念頭に今後 S3 を利用していきたい。

AWS SDK を活用する
プレフィックスの使い方を理解する
用途に合わせたバケット選定

dig s3.amazonaws.com A +short すると確かにばらけていることが確認できた。こうやってリクエスト先を分散させているんですね

AWS-28 大規模クラウドインフラ設計、構築案件の歩き方

公式概要

クラウド技術のコモディティ化により、エンタープライズ分野では近年、AWS 上での大規模なアプリケーション開発が一般的になりつつあります。これを支えるクラウドインフラ設計についても、求められる非機能要件の高度化と関連する AWS サービスの多様化に伴って、多人数でのチーム設計やアプリケーションチームとの効果的な連携が求められることが増えてきました。本セッションでは、AWS Professional Services の豊富な実績を元に、クラウドインフラの設計・構築およびテストを円滑に進める上での実践的知見をご紹介します。

登壇者

仲谷岳志様
アマゾンウェブサービスジャパン合同会社
プロフェッショナルサービス本部プリンシパルビッグデータコンサルタント

内容メモ

大規模インフラには以下の特徴、解くべき課題がある。またそれぞれの解決策として以下がある。

関係者が増える
- 設計の骨組みづくり
- アプリ / インフラチームの責任分解 -コーディングルール
想定外が増える
- クリティカルパスの特定
- 展開手順の整備
- コスト管理は今すぐ始める
堅牢さが求められる
- クラウドリソースのテスト
- 静的解析

内容が非常に濃かったので自分の中でなるほどーと思ったところに絞って書きます。詳細はぜひぜひ資料をダウンロードして読んでほしいです。

設計の骨組みづくり

まずやるべきことは「設計書一覧の作成」可能な限り洗い出して詳細に書くことで抜け漏れ防止や誰が担当するかを明確にできるなどのメリットがある。例として出された設計書一覧が以下でかなり数が多い。自分の設計がいかに不足していたかを感じる。

設計書一覧（例）

設計基本方針
- 設計方針
- アーキテクチャー概要
- 命名規則
- 略称一覧
- 設計書一覧
- レビュー方針
アカウント設計
- アカウント設計
- Organizations 設計
- SCP 設計
ネットワーク設計
- VPC 設計
- Direct Connect 設計
- Transit Gateway 設計
- Route 53 設計
- Network Firewall 設計
- AWS WAF 設計
ゲートウェイ設計
- CloudFront 設計
- API Gateway 設計
- NLB 設計
- ALB 設計
- IoT Core 設計
コンピューティング設計
- Lambda 設計
- ECS/Fargate 設計
- EC2 設計
データ設計
- Aurora 設計
- DynamoDB 設計
- S3 設計
- OpenSearch Service 設計
- ElastiCache 設計
インテグレーション設計
- SQS 設計
- SNS 設計
- SES 設計
- Kinesis Data Streams 設計
- Firehose 設計
- Step Functions 設計
- EventBridge 設計
- Parameter Store 設計
- Cognito 設計
セキュリティ設計
- セキュリティ設計方針
- 暗号化設計
- 認証認可設計
- 脆弱性対策設計
- セキュリティ監視設計
セキュリティサービス設計
- IAM Identity Center 設計
- IAM 設計
- Security Hub 設計
- GuardDuty 設計
- Config/Config Rules 設計
- AWS KMS 設計
- ACM 設計
- CloudTrail 設計
- Secrets Manager 設計
- IAM Access Analyzer 設計
運用設計
- 運用設計方針
- 監視設計
- 通知設計
- バックアップ・リストア設計
- 基盤メンテナンス設計
- ハウスキーピング設計
- 上限管理設計
- 踏み台設計
- タグ設計
- コスト管理設計
- 証明書管理設計
- 災害対策設計
ログ設計
- ログ設計方針
- 収集設計
- 加工設計
- 蓄積設計
- 検索設計
CICD 設計
- CICD 設計方針
- ブランチ戦略
- 利用ツール
- IaC コーディングルール
- IaC テスト方針
- レポジトリ設計
- パイプライン設計
- デプロイ設計
- ECR 設計

... など

設計書の一覧を作ったあとの流れ

設計書項目の整理
- いわゆる ADR を残す
- 設計の理由を残すべき
- 今後の設計改定への布石にもなる
詳細設計書の取り扱い方針を決める
- ex. 初版は IaC + 文書、以降は IaC を正とする
進捗を定義する

静的解析について

大規模な開発は IaC で管理される。IaC 開発におけるポイントはセキュリティチェック。セキュリティリスクの洗い出しをできるように個々の開発環境やレビュープロセス、 CI/CD に静的解析ツールを導入することが必要。ただし例外はあるので都度設定すること。

CloudFormation や CDK であれば cdk-nag を利用する手がある。

その他

コスト管理は今すぐ始めるべき
- Dev は失敗する環境、だからこそ高騰するコストがある
- ex. CloudWatch Logs に大量のトレースが流れる可能性
クリティカルパスの特定
- クリティカルパスの例
  - 手動展開のほうが合理的なパターン
  - IaC で実施できないパターン
  - 大規模インフラの特徴「社内調整や申請が必要」
- 思わぬところで時間を食いかねないので早めに確認すべき
展開手順の整備
- 大規模開発の場合、段階的に繰り返し展開することになる
- IaC/手動/申請を区別し、依存関係を踏まえつつ手順を組み立てる
- 展開手順は自分が読むわけではないのでローコンテキストで書く
IaC に置けるテストの考え方
- 単体テスト：実環境の状態を確認。設計通りかをチェック
- 結合テスト：疎通性を確認。コード、アプリ、運用インフラが正常に疎通できるか
- 負荷テスト：性能テスト。性能要件が満たせているかをチェック

感想

設計書の設計書を作るという概念が自分にはなかったので非常に参考になりました。明日から実践していこうと思います。
またこの設計書の扱いを明確に「初版は IaC + 文書、以降は IaC を正とする」と決めてしまうのも非常によいと感じた。コードを見ればいい派、理由がわからないから文書で残すべき派、いままでいろいろな派閥と出会ってきてあまり決めずにいた。セッションの中で最初は人の会話をスムーズにさせるため文書を用い、その後はメンテナンス性を加味してコードを正とするのはよい落としどころになりそう。

セッションの中では設計書の例が示されたり、静的解析のツールの例が出されたりと非常に具体的な内容が多く含まれていました。自分のなかで持てていなかった Tips を多く得ることができたので、今後のエンジニア人生に活かしていきたいです。

AWS-57 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法

公式概要

フレームワークを活用した典型的なWeb三層のアプリケーションで開発をスタートし、最初はスピード感のある開発が行えていたのに、徐々に機能が追加されていき、気がつくと様々な機能が密結合になり、単一のデータベースを様々な機能が利用していて、変更の影響がどこにあるか分かり難くなってきます。次第に機能追加に時間がかかるようになり、古いコードを変更することが怖くなり、元のコードを残したまま、コードを追加するようになって益々複雑化していきます。このような状況を改善するためには適切な粒度でサービスを切り出して置き換えていくことが必要です。では、どのようにすれば正しい粒度でサービスを分割ができるでしょうか。本セッションでは DDDをベースとしてEvent Storming を活用した境界づけられたコンテキストの発見による具体的なサービスの分割方法をご紹介します。

登壇者

福井厚様
アマゾンウェブサービスジャパン合同会社
プロトタイプ＆カスタマーエンジニアリング本部 Developerスペシャリストソリューションアーキテクト

内容メモ

Why なぜリアーキテクチャが必要になるのか︖

小規模ならばフレームワークの機能によってシンプルな実装ができる。ビジネスロジックも CRUD や OR マッパーで済む。

ただし成長するにつれて...
- データの呼び出しが複雑に
- ビジネスロジックがほかのレイヤに漏れだす
結果
- コードの見通しが悪くなり機能追加や修正の影響が不明瞭になる
- ライブラリやスキーマ変更の影響が広く

→ マイクロサービス化を検討。

マイクロサービスのメリット
- デプロイの影響範囲が狭まる
- 機能的な自立性と単一責任の原則
- 開発速度の向上
- スケーリングの最適化
- コストの最適化
マイクロサービスがいい選択肢ではないとき
- サービスの分割単位が不明瞭
- 開発メンバが少数
- 単純な CRUD のみの小規模アプリケーション
- 正当な理由がない

How どうやってサービスを分割するのか

高品質なソフトウェアモデルを設計するためのソフトウェア開発手法であるドメイン駆動設計（DDD）を活用。

ポイントはビジネスドメインを理解し、境界付けられたコンテキストからドメインを定義すること。つまりビジネスに精通した人の言語が伝わる範囲で責務を分割する。

ex. ユーザでも見るシステムからしたら「入札者」「購入者」「配送先」

ドメイン分割の手段として Event Storming があり、業務から境界付けられたコンテキストとモデルを導き出すことができる。 Event Storming を理解するためのおすすめブログとして SODA さんの以下の記事をおすすめしていただきました。

zenn.dev

ドメインモデルの実装方法

TDD（テスト駆動開発）がドメインモデルと相性がよい。

以下の流れでテストは作成

ユースケースシナリオをホワイトボードに書き出す
ユースケースからシーケンス図を作成しメソッドを洗い出す
シーケンス図で定義した振る舞いをテストに落とし込む

詳細は以下の書籍を確認。「テスト駆動開発」︓Kent Beck（著）和⽥卓⼈（翻訳）オーム社 2017/10/14

ドメインモデルのシステムへのマッピング

ビジネスドメイン全体をコンテキスト境界で分割
コアドメインとサブドメインを定義
ドメイン間をドメインイベントでつなげる
出来上がったモデルを論理アーキテクチャに落とし込む
1. 非機能要件を設計する
2. 実際に認証をするならーキャッシュするならーなどの機能を用意
3. 世にあるテンプレパターンに落としこむ（自分はよく知らないが...SAGA, CQRS など）
4. ADR を記述して管理する
5. この段階ではまだAWSのサービスには落とし込まない！
論理アーキテクチャから物理アーキテクチャに落とし込む
1. AWSのサービスにマッピング
2. AWS Well-architected の推奨を利用して非機能要件を満たす
3. ADR を更新する

感想

自分があまりソフトウェア開発手法周りに触れてこなかったものの話は聞く DDD や TDD といった手法についてざっと流れを知ることができ、勉強になった。周りでも分割が必要なのではないかと考えられるシステムがあったり、実際にこういった手法を取り入れている方がいるのをちらほら見かける。話を聞きつつ参考として教えていただいた書籍やブログを通して知見を深めていきたい。

ドメイン駆動設計を自分が過去ちらっと聞いた際に「ドメイン知識に精通した人」に沿ってシステムを設計すると聞いて、システムを作るならそのドメインに精通してなきゃつくれないのは当然では？エンジニアが作りたいものを作ってしまう人間であるがゆえに出来上がってしまった考え方か？と思ってしまっていました。今回の話を聞いて少なくともその認識は違うな、と感じました。正直イメージがつかないところも多かったが、大局を見ることができたと思われるので気になるところを深堀しつつ日々に生かしていきたい。

まとめ

今回の AWS Summit では Level 300 以上のものを中心に自分の分野に関連するセッション、ちょっとずれているけど薄くかかわりのあるセッションを中心に聞いてきました。自分にとってちょうどいいレベル感で様々なお話を聞くことができたおかげで自分の知識や考え方が広がったり、深めたりできました。直近で使えるものから将来的に使えるものまで広く知ることができたので、今後の活動に活かしていきたいです。

2024-06-01

AWS Systems Manager Automationを体験してみる

AWS

みなさん、AWS Systems Manager は使っていますでしょうか。 Systems Manager といってもたくさんの機能があり、便利にインスタンスへ SSH できる Session Manager や、インスタンスのパッチ管理を自動で行う Patch Manager など様々な機能が提供されています。

Systems Manager の中に「Automation」という機能があります。これは runbook と呼ばれる YAML/JSON 形式のドキュメントに処理内容を記載することで簡単に自動で AWS リソースの修正ができるよ、というサービスです。

自動化？ドキュメントの作成...？ちょっとめんどくさそうだなぁと思ってしばらく触らずにいましたが、実際に触ってみると 実用的なサンプルの runbookがある、 コンソールから手軽に実行を試せる など、かなりとっかかりやすい機能でした。本ブログではまだ AWS Systems Manager Automation を使ったことがないエンジニア向けに AWS が用意したマネージドな runbook を実際に実行してみる手順を紹介します。

概要
- AWS Systems Manager Automationとは
- 本ブログで取り上げる内容
実践編 - コンソールからサンプルの runbook を実行する
まとめ
宣伝

概要

AWS Systems Manager Automationとは

オートメーションは、AWS のサービス (Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon Simple Storage Service (Amazon S3) など) でのメンテナンス、デプロイ、および修復に関する一般的なタスクを簡素化するための AWS Systems Manager の機能です。 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-automation.html

AWS Systems Manager には AWS 環境におけるインフラやアプリケーションの管理を簡単にするためのツールが様々含まれています。そのうちの1つである「Automation」はタスクの自動化に特化したサービスです。

自動化の内容は runbook と呼ばれる YAML/JSON 形式のドキュメントに記載します。デフォルトで AWS より提供されている runbook があり、コンソールから手軽に実行を試すことができます。もちろん自前で用意も可能です。EC2 インスタンスの起動や停止などにとどまらず、設定の変更など様々自動化を行うことができます。

Automation のカスタマイズ性は非常に高く、実行の内容だけでなく実行のトリガーをカスタマイズも可能です。CloudWatch のメトリクスをトリガーにして runbook を実行したり、Security Hub、Config の検知をトリガーにして runbook の実行が可能です。

これらの AWS Systems Manager Automation の機能を活用することで、AWS インフラ運用に携わるエンジニア、社内の AWS 環境を管理するエンジニア、セキュリティ面での対応を担当するエンジニアなど様々なロールのエンジニアの業務効率化に貢献できます。

本ブログで取り上げる内容

本ブログでは AWS Systems Manager Automation の機能を活用して実際に作られた問題があるリソースをコンソールから runbook を実行して修正を試みます。 Automation を用いることで「大量に実行する処理」や「手順が複雑なタスク」を自動化し、業務効率化に貢献できることを体感していただければと思います。 runbook は Config や Security Hub、CloudWatch など様々なトリガーを起点に自動で実行できますが、それはまた別の記事で取り上げます。

実践編 - コンソールからサンプルの runbook を実行する

本章では外部に公開された S3 バケットを作成し、そのバケットの外部公開設定を閉じる runbook を実行する手順を紹介します。 S3 バケットの外部公開設定を閉じる runbook は AWS Systems Manager Automation にデフォルトで用意されており、実行することで外部公開を閉じることができます。

デフォルトで用意されている runbook は AWS Systems Manager の Automation から Execute のボタンを押すことで確認できます。
https://ap-northeast-1.console.aws.amazon.com/systems-manager/automation/execute/

AWS Systems Manager Automation から Execute automation を選択

1. 外部公開された S3 を CloudFormation で作成

以下の CloudFormation テンプレートを使って、外部公開された S3 バケットを作成します。インターネット上に公開されたバケットを作成するため、会社の AWS アカウントで適用したり放置したりしないよう注意してください。

AWSTemplateFormatVersion: "2010-09-09"
Description: "S3 Bucket with Public Access Allow Configuration"

Resources:
  S3BucketSamplePublicReadAllow:
    Type: "AWS::S3::Bucket"
    Properties:
      BucketName: !Sub "sample-public-read-allow-${AWS::AccountId}"
      PublicAccessBlockConfiguration:
        BlockPublicAcls: false
        IgnorePublicAcls: false
        BlockPublicPolicy: false
        RestrictPublicBuckets: false

  S3BucketSamplePublicReadAllowPolicy:
    Type: "AWS::S3::BucketPolicy"
    Properties:
      Bucket: !Ref S3BucketSamplePublicReadAllow
      PolicyDocument:
        Statement:
          - Effect: "Allow"
            Principal: "*"
            Action: "s3:GetObject"
            Resource: !Sub "arn:aws:s3:::${S3BucketSamplePublicReadAllow}/*"

CloudFormation 適用の詳細手順

上記のテンプレートをコピーし、ファイルに保存
CloudFormation のコンソールへアクセス
「スタックの作成」から「新しいリソースを使用（標準）」を選択
テンプレートの指定欄で「テンプレートファイルのアップロード」を選択し、上記のテンプレートファイルをアップロード
スタック名として任意の名前を設定し、「次へ」
スタックオプションの設定はデフォルトのまま、「次へ」
確認して作成に表示される内容を確認し、「送信」
少し待つとスタックのステータスが「CREATE_IN＿PROGRESS」から「CREATE_COMPLETE」に変わり、バケットが作成される

2. 作成した外部公開バケットを確認

外部からアクセスできることを確認

インターネットから 1. で作成した S3 バケットに外部からアクセスできることを確認します。適当なファイルを用意し、S3 バケットにアップロード、ファイルの URL を取得し、ブラウザでアクセスしてファイルが表示されることを確認します。

ファイルのアップロードと外部アクセス確認の詳細手順

S3 のコンソールへアクセス
1. で作成したバケット sample-public-read-allow-<<AWSアカウントID>> を選択
「アップロード」をクリックし、txt ファイルなど適当なファイルをアップロード
ステータスが成功になったことを確認し、「閉じる」
アップロードされたファイルをクリックし、詳細画面から「オブジェクト URL」をコピー
ブラウザでコピーした URL にアクセスし、ファイルが表示されることを確認

外部公開設定の内容を確認

作成した S3 バケットの「アクセス許可」タブよりどのように外部公開の設定が行われているかを確認します。

ブロックパブリックアクセスポリシーにはなにもチェックがなく、アクセスブロックをしない状態になっています。バケットポリシーには Principal: "*" と書かれておりインターネットからを含むあらゆるユーザに s3:GetObject が許可されていることが確認できます。

3. runbook を実行する

コンソールから runbook を実行して、外部公開設定を閉じます。

AWS Systems Manager の Automation 画面を開く
「Execute automation」をクリック
「AWS-DisableS3BucketPublicReadWrite」を検索し、「Next」
Input Parameters に以下の内容を入力し、「Execute」
- S3BucketName に 1. で作成したバケット名「sample-public-read-allow-＜AWS アカウント ID＞」
Execution detail の画面に遷移するので Overall Status が Success となれば成功

4. 実行結果の確認

実際に外部公開設定が閉じられていることを確認します。ブラウザでサンプルとして置いたファイルの URL にアクセスし、ファイルが表示されないことを確認します。またどこの設定が変更されたか、S3 バケットの詳細画面から確認します。

「任意のアクセスコントロールリストを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする」「任意のパブリックバケットポリシーまたはアクセスポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする」にチェックが入りブロックされていることがわかります。

まとめ

本ブログでは AWS Systems Manager Automation の機能を活用して、外部公開された S3 バケットの設定を閉じるサンプルの runbook を実行する手順を紹介しました。自動化といえどかなり手軽にできることがわかります。実際に業務で利用する際には「独自のユースケースに沿った runbook を作成する」「検知されたものを自動で修復する」、「AWS Organizations に向けて同様の runbook を展開する」など様々な課題があります。それらについてはまた別の機会に取り上げたいと思います。まずはいろいろなサンプルの runbook を実行してみて、AWS Systems Manager Automation の機能を体感してみてください。

宣伝

現在、AWS Community Builder である @nishikawaakira と一緒に AWS Systems Manager Automation のワークショップを企画しています。オリジナルの runbook を作成する手順を体験しながら、Automation の機能や使い方について学ぶことができるワークショップを実施する予定です。詳細は決まり次第 X(旧 Twitter) 等でアナウンスするのでご興味のある方はぜひフォローをお願いします。

2023-12-02

AWS re:invent参加にあたって知っておいたほうが少し快適になること

AWS

本稿は、ZOZO Advent Calendar 2023 シリーズ 6 2日目の記事です。

AWS re:invent 2023に参加してきました。弊社からは7名が参加し、うち2人は昨年のre:invent2022にも参加したメンバーでした。私も2回目の参加であり、初参加メンバーの疑問点に答えたりアドバイスをする機会が多々ありました。

会社としての参加ブログは別途投稿されますが、今回はre:inventに関して社内で一緒に参加したメンバーにしたアドバイスや個人的に知っておいたほうがいいと感じた内容をまとめます。なにも知らない状態でre:inventに参加すると知らないワードがいろいろ出てきたりとハードルが高いので、もし参加する機会があればこの記事を参考にしてもらえればと思います。

この記事はre:invnentに参加するまでの工程すべてを網羅しているわけではないです。要所要所で使えるtipsなどをまとめた記事であるため、実際に行かれる場合はほかの方の記事も参考にしていただければと思います。

そもそもre:invnetとはなにか
事前に知っておいたほうがいい、調べておいたほうがいい編
準備編
移動編
- 入国審査について
- バッジのピックアップ
re:invent現地編
あとがき
- 更新履歴

そもそもre:invnetとはなにか

AWS re:InventはAWSが主催するクラウドコンピューティングに関連するカンファレンスです。 AWSの製品発表などを含む基調講演や、AWSのサービスを使ったハンズオンラボ、AWSのパートナー企業による展示ブースなどがあります。 2012年から毎年ラスベガスで開催されており、今年で12回目を迎えます。

reinvent.awsevents.com

事前に知っておいたほうがいい、調べておいたほうがいい編

初めてで海外に不安があるならばツアーに参加するのが良い

re:inventはラスベガスの会場で開催されます。そもそも日本国外であり、旅慣れていない場合にはかなりハードルが高いです。近畿日本ツーリストさんが例年ツアーを開催しており、ツアーに参加すると飛行機の手配やホテルの手配などがすべてセットになっているので、初めての参加者にはおすすめです。移動の際にも添乗員さんがついてくださり空港などでのアクシデントの際にも安心です。

knt.reinventjapantour.com

昨年はツアーを利用してre:inventに参加し、ある程度土地勘がついたため今年は個人手配で参加しました。

事前勉強会が開催される

Connpassなどで調べると事前勉強会が多数開催されています。事前に今までのアップデートのインプットができるだけでなく、参加者同士の交流の場にもなります。

都合がつけば行くのをおすすめします。

セッションの予約

re:inventではたくさんのセッションが開催されます。セッションは事前に公開され、一覧が申し込んだポータルサイトから見れるようになっています。予約開始は適宜メールで連絡が来ますが10月末ごろから始まります。気になるセッションはお気に入り登録して予約開始を待ちましょう。

またここでセッション以外に「breakfast」「lunch」と検索して出てくる「Monday lunch」などのセッションもお気に入り登録しておくと良いです。後ほどセッションと一緒にカレンダーでお気に入りしたセッション一覧が表示されるためランチなどの時間を確認できます。

セッションの予約開始は深夜になるので本気で参加したいセッションがある場合は頑張って予約するほうがいいです。予約の埋まってしまったセッションは「walk-up」という形で当日参加できる場合がありますが、セッション開始前に会場へ行って並ぶ必要があります。大半のセッションはwalk-upに並ぶことで入れるので予約できなかったからといって落ち込む必要はありません。

今回自分は朝起きてから予約をしようとしたら予約が埋まっていたセッションが多かったのであまり予約できていない状態で参加しましたが、walk-upで大半のセッションに参加できたので問題なかったです。

情報が集まるSNSをフォローする

re:inventに関する情報はいろいろな方が発信してくださっています。自分は以下のFacebookのグループに参加し、様々な情報を得ていました。

www.facebook.com

イベント情報やセッション予約の開始情報、ラスベガスの情報などが集まっているので、参加するならフォローしておくと良いと思います。今年もとてもお世話になりました。

準備編

現地でのインターネット

会場にはWi-Fiがあり、かなり早いためインターネットには困りません。しかしながら会場外ではWi-Fiがないため個人で調達する必要があります。

いつの間にか空港からSIMの自販機はなくなっており、インターネットを利用するには現地のSIMを契約するか、日本でモバイルルーターをレンタルするかのどちらかになります。端末がeSIMに対応しているのであれば個人的にはeSIMの購入をおすすめしています。 eSIMとはインターネット経由でSIMが買える機能であり、最近の端末であれば物理のSIMとは別に設定できます。

自分は会社の先輩に教えてもらったAiraloというサービスを利用してeSIMを購入しました。 eSIMであればモバイルルータを持ち歩く必要もなく、かなり安価にインターネットを利用できるのでおすすめです。

www.airalo.com

今回は30日5GBで$16の契約にしました。リファラルコードがあるのでもしよければ使ってもらえると嬉しいです。

KAZUYO7955

スーツケースには余裕を持たせる

re:inventに参加するとたくさんのお土産をもらえます。持ち帰るのが大変なほどもらえるので、スーツケースには余裕を持たせておくと良いです。自分は半分開けてたスーツケースが帰りには埋まっていました。

ホテルに給湯器はない

ラスベガスのホテルには共通して部屋に給湯器がありません。聞いたところの話によるとできるかぎり部屋からでてカジノで楽しんでほしいから、などの戦略のようです。

部屋で持参のインスタント食品やコーヒーを飲みたい場合にはお湯を沸かす手段がないためロビーに電話して持ってきてもらうか給湯器を持っていくの2択になります。ロビーに頼むとチップなどもありすこし大変なため自分は折り畳みの給湯器を購入して持っていきました。

購入する際には日本と違って120Vの電圧に対応できるものを購入する必要があるので注意してください。

AWSイベントアプリを入れる

AWSが公式で出しているAWSのイベントアプリがあります。アプリを利用することでセッション情報の確認、予約だけでなく、会場内の案内やスケジュールの確認などができます。

様々な情報が集まっているので、参加するならば必須のアプリです。

移動編

日本を出てからラスベガスに着くまでの移動の間で知っておいたほうがいいことをまとめています。

入国審査について

多くの方が入国審査に関して英語で何を聞かれるか不安に思っていると思います。 re:invnentに参加する際はかなり簡単です。「何の目的で来たのか」を聞かれた場合には「AWSのカンファレンスに参加するため」と答えればOKです。入国審査官が「AWS ?」って聞いてくるぐらいにはre:invent参加者が空港に溢れているため「I'll go to AWS conference」で通じます。

バッジのピックアップ

空港でre:inventに参加するための名札をピックアップできます。ピックアップには「AWSイベントアプリに表示されるQRまたは参加メアドの入力」と「パスポート」が必要になります。事前にイベント申し込みページから顔写真をアップロードしていない場合はここで撮影された写真を名札に印刷してくれます。飛行機の長時間移動後の疲れ切った写真になってしまうため可能ならば事前にアップロードしておくのがおすすめです。

re:invent現地編

会場について

会場は複数のホテルにまたがっています。会場の移動はシャトルバス、または歩きの移動がメインとなり、どちらもかなり時間がかかります。セッションの都合でホテルを移動する必要がある場合はかなり余裕を持って移動する必要があります。

会場が広いためシャトルバスでも歩きでも移動には40分程度かかるものとして自分は計算していました。

シャトルバスの時間はアプリで確認できます。行くべき部屋等々は「Ask me」と書かれたシャツを着ているスタッフさんに聞くと助けてくれます。

Keynoteについて

Keynoteは基調講演のことであり、月曜日のみ夜、火水木は朝に開催されます。基調講演では新製品の発表などなど盛りだくさんの内容であり、とても盛り上がるためせっかくreinventに来たのであれば参加することをおすすめします。基調講演は席の予約ができないため、いい席へ行きたい場合は早めに会場に行って並ぶ必要があります。

基調講演のみ同時通訳が行われています。会場を入って右手に同時通訳レシーバを受け取る場所があるため受け取るのをおすすめします。

SWAG

re:inventに参加するとたくさんのお土産をもらえます。このお土産のことをSWAGと呼びます。 SWAGはメインホールの交換所でもらえるものと、各会場のブース、イベントでもらえるものがあります。例年確実にもらえるものとして以下のようなものがあります。

| SWAG | 条件 | | --- | --- | | パーカー | メインホールの交換所に行く | | 水筒 | メインホールの交換所に行く | | 認定者Tシャツ | AWSの資格を持った状態でメインホールの交換所に行く |

EXPO

EXPOは展示ブースのことであり、AWSのパートナー企業がブースを出しています。 SWAGをもらえるホールの隣で開催されます。入れる時間が決まっているのでイベントアプリで時間を調べていくようにしましょう。各社の紹介を聞いたりSWAGをもらえたりできます。

個人的におすすめのEXPOブースはAWSのブースです。直接各サービスを作っているエンジニアと話して質問できたりオリジナルアイテム、AWSのバウチャーをもらえたりします。

セッションの参加について

アプリで会場を調べて行くことになります。予約していた人はセッション開始の10分前まで優先的に入場でき、10分前を過ぎると予約が解放され、walk-upの人も入場できるようになります。自分は予約していればぎりぎりでも大丈夫だろうと思っていたのですが予約が解放されてwalk-upの方で埋まってしまい参加できなかったセッションがあったため同じミスをされる方が今後この記事を機に減ることを願います。

ご飯について

re:invent会場では朝ごはんとお昼御飯がでます。セッションの予約の欄にて「lunch」などのセッションをお気に入り登録したほうがよいと書きましたが、ここで表示される時間内にMeal会場へ行くとご飯をもらえます。

その場で食べる形式と「Grab and Go」というお弁当形式の2種類があります。 Grab and Goはお弁当をもらって会場外で食べることができます。セッションが詰まっている際などにはこちらがおすすめです。

各会場のホテルごとに食事の内容が少し違うらしいのです。気になった方はいろいろな会場に行ってみると良いと思います。

re:play とは

会場でちらほら聞くことになる「re:play」とは何なのか。 re:inventの実質最終日である木曜日の夜に行われるイベントの名前です。アーティストの生ライブやDJを見ることができたりご飯が食べられたりします。

注意点として「かばんの持ち込みが不可」「屋外なので寒い」などあります。詳細な注意事項は会場内に水曜日あたりから出現する立て看板にあるのでそちらを参考にしてください。勉強抜きで思いっきり楽しむイベントです。会場への移動はシャトルバスになり、各ホテルから運行されています。運行時間等はこれもAWSイベントアプリで確認できます。

また参加するとTシャツのSWAGが受け取れるので忘れずに受け取るようにしましょう。

あとがき

AWS re:inventに2回目の参加をしていろいろと思ったTipsのようなものをまとめました。最初に書いたように要所要所で使えるtipsなどをまとめた記事であるため、実際に行かれる場合はほかの方の記事も参考にしていただければと思います。

また思い出すこと等あれば適宜アップデートしていきます。ここまでご覧いただきありがとうございました。

更新履歴

日付	内容
2023/12/02	初版公開

2022-12-21

Datadogで使用量情報をAdmin権限以外でも見れるようにする

Datadogを使用していた際にメンバーの「どれくらい使用しているかわからないんだよね〜」というつぶやきを見かけました。使用量がわからないと思わぬ課金が発生していてもすぐ気づけ無い等の問題があるためDatadogのカスタムロールを用いてUsageの見れる権限を作成して対応しました。

本記事ではDatadogno使用量(Plan & Usage)を見れるロールを作ることを題材にDatadogのカスタムロールの作成方法を紹介します。また自分の利用方法では複数のDatadog Organizationがあり、いちいち手作業でカスタムロールを作成するのは大変だったのでPythonでカスタムロールの作成をスクリプト化し、自動化をしました。こちらのスクリプトについても紹介します。

今回使用する「カスタムロール」機能はEnterprise版の機能になりますのでご注意ください。

カスタムロールの作成と変更は、オプトイン Enterprise 機能です。ご使用のアカウントでこの機能を有効にしたい場合は、Datadog のサポートチームにお問い合わせください。*1

Datadogの権限について
カスタムロール
- カスタムロールの作り方
まとめ

Datadogの権限について

Datadogの権限については以下のページにまとまっています。デフォルトで存在する権限は「Datadog 管理者ロール」「Datadog 標準ロール」「Datadog 読み取り専用ロール」の3つです。これらの権限をメンバーに付与することで権限管理をできますが、より柔軟に権限を振りたい場合には「カスタムロール」を用いて権限を作る必要があります。

docs.datadoghq.com

「管理者」しかPlan & Usageページに表示される「使用状況レポート」にアクセスできず、メンバーがDatadogの使用量を意識しにくいという課題がありました。

docs.datadoghq.com

ここでカスタムロールを作成してメンバー誰でもPlan & Usageページを見れるようにしてハッピーになろうぜ、というのが今回の記事になります。

カスタムロール

datadogの提供するアクセス許可を組み合わせてオリジナルのアクセス権限を作成することができます。アクセス許可の種類については以下のページにまとまっています。

docs.datadoghq.com

カスタムロールの作り方

カスタムロールの作成は以下のページを参考に作成しました。

docs.datadoghq.com

カスタムロールの有効化

カスタムロールはEnterprise版のオプトイン機能になります。事前にカスタムロールの機能を有効化するために問い合わせページやサポートの方にカスタムロールを有効化したい旨を伝え有効化してもらいましょう。

手動のロールの作成

Datadog Roles ページに移動
ページ右上隅 New Role を選択
ロールに名前をつける
- 今回は「BillingReadRole」という名前にしました
権限の編集
- 名前の下に付与される権限一覧が表示されます
  - デフォルトでReadに関する権限がいくつか付与される
- 追加でBillingとUsageを見るための権限にチェック
  - Billing Read
  - Usage Read
保存

これで無事にカスタムロールが作成できました🙌

ロール作成の自動化 with Python

何個かDatadogのOrganizationを持っていると同一のロールをすべてのOrganizationで作りたいなどの要件が出てきます。そんなときには何かしらの自動化手段を考えたいものです。

DatadogのRoleを管理する際には「terraformを用いて管理する案」や「API経由で作成する案」があります。今回はPythonでAPI経由で作成に挑戦しましたのでそちらを共有します。

1. 操作するアカウントのAPIキーを取得する

PythonからDatadogを操作するには API Key と Application Key が必要になります。

以下の手順でそれぞれ取得し、どこかにメモします。これらの情報が流出してしまうと自由にDatadogを操作できてしまうため管理には気をつけてください。

Organization Setting を開く
ACCESS -> API Keys からキーを作成し保存
ACCESS -> Application Keys からキーを作成し保存

2. Python実行用の環境作成

Pythonで操作するにあたり、Datadog社の公開している datadog-api-client-python を利用していきます。

ライブラリのインストール
pip install datadog-api-client
アクセス情報を環境変数にセット
- デフォルトでこのライブラリは DD_API_KEY と DD_APP_KEY に書かれたAPI Key とApplication Keyを用いてDatadogにアクセスします
- 1. で保存したキーを環境変数に保存しましょう
- また時折 DD_SITE なる環境変数を求められることがありました。こちらもセットしておきましょう

❯ export DD_API_KEY=<取得したAPIキー>
❯ export DD_APP_KEY=<取得したAPPキー>
❯ export DD_SITE=datadoghq.com

3. 付与する権限のIDを調べる

APIリファレンス > ロール: List roles のサンプルコードを用いて手動で作成した BillingReadRoleにはどのような権限がついているか確認していきます。Python実行用の環境作成でセットした認証情報をもとにDatadogにログインされます。list_role を実行することで ROLE_DATA_ATTRIBUTES_NAME のロール名についているPermissionを見ることができます。

サンプルがそのままだと動かなかったので少しだけ修正しています。

# from os import environ
from datadog_api_client.v2 import ApiClient, Configuration
from datadog_api_client.v2.api.roles_api import RolesApi

# there is a valid "role" in the system
ROLE_DATA_ATTRIBUTES_NAME = "<BillingReadRole 作成したロール名>"

configuration = Configuration()
with ApiClient(configuration) as api_client:
    api_instance = RolesApi(api_client)
    response = api_instance.list_roles(
        filter=ROLE_DATA_ATTRIBUTES_NAME,
    )

    print(response)

❯ python3 ./list_roles.py
{'data': [
  {'attributes':
    {
      'created_at': datetime.datetime(2022, 2, 18, 11, 51, 54, 42646, tzinfo=tzutc()),
      'modified_at': datetime.datetime(2022, 2, 18, 11, 51, 54, 89124, tzinfo=tzutc()),
      'name': 'BillingReadRole',
      'user_count': 1
    },
    'id': '01234567-hoge...',
    'relationships': {
      'permissions': {
        'data': [
          {'id': 'd90f6830-d3d8-11e9-a77a-b3404e5e9ee2', 'type': 'permissions'},
          {'id': '46a301df-ec5c-11ea-aa9f-970a9ae645e5', 'type': 'permissions'},
          ....

data として id が出ていますがこのままではなんのPermissionなのかわかりません... 別途Permissionの内容を見るAPIリファレンス > ロール: List Permissionを実行してみましょう。

from datadog_api_client.v2 import ApiClient, Configuration
from datadog_api_client.v2.api.roles_api import RolesApi

configuration = Configuration()
with ApiClient(configuration) as api_client:
    api_instance = RolesApi(api_client)
    response = api_instance.list_permissions()

    print(response)

❯ python3 ./list_permission.py 
{'data': [
    {
        'attributes': {
            'created': datetime.datetime(2018, 10, 19, 15, 35, 23, 734317, tzinfo=tzutc()),
            'description': 'Deprecated. Privileged Access (also '
                'known as Admin permission) has been '
                'replaced by more specific '
                'permissions: Access Management, Org '
                'Management, Billing Read/Write, '
                'Usage Read/Write.',
            'display_name': 'Privileged Access',
            'display_type': 'other',
            'group_name': 'General',
            'name': 'admin',
            'restricted': False
        },
        'id': '984a2bd4-d3b4-11e8-a1ff-a7f660d43029',
        'type': 'permissions'
    },
    {
        'attributes': {
            'created': datetime.datetime(2018, 10, 19, 15, 35, 23, 756736, tzinfo=tzutc()),
            'description': 'View and edit components in your '
                'Datadog organization that do not '
                'have explicitly defined permissions. '
                'This includes configuring events, '
                'facets (except logs), and saved '
                'views.',
            'display_name': 'Standard Access',
            'display_type': 'other',
            'group_name': 'General',
            'name': 'standard',
            'restricted': False
            },
        'id': '984d2f00-d3b4-11e8-a200-bb47109e9987',
        'type': 'permissions'
    },
    .... 省略
}

どうやら id と紐づく attributes が存在し、権限の名前や説明を設定しているようです。BillingReadRole についていた 46a301df-ec5c-11ea-aa9f-970a9ae645e5 のidを出力されたjsonから検索すると以下が見つかりました。

description: View your organization's subscription and payment method but not make edits.
display_name: Billing Read

カスタムロールを作成し、付与したい権限のIDを与えることで目的の権限を作成することができそうです。idについては github 上で調べたところ同じ値が数多く見つかり、Organization毎に異なるものでは無いようでした。

4. ロールの作成と権限の付与

APIリファレンス > ロール: Create role を用いてカスタムロールを作成していきます。リンク先のサンプルコードでは権限の何もついていないロールを作成していますが、やってみたところ権限付与もCreateRoleと同時に実行可能でした。

以下のサンプルでは「Billing Read」「Usage Read」の権限を付けた権限を「billing-read-role」の名前でカスタムロールを作成しています。実行後には作成したカスタムロールのidを表示しています。

from datadog_api_client.v2 import ApiClient, Configuration
from datadog_api_client.v2.api.roles_api import RolesApi
from datadog_api_client.v2.model.permissions_type import PermissionsType
from datadog_api_client.v2.model.relationship_to_permission_data import \
  RelationshipToPermissionData
from datadog_api_client.v2.model.relationship_to_permissions import \
  RelationshipToPermissions
from datadog_api_client.v2.model.role_create_attributes import \
  RoleCreateAttributes
from datadog_api_client.v2.model.role_create_data import RoleCreateData
from datadog_api_client.v2.model.role_create_request import RoleCreateRequest
from datadog_api_client.v2.model.role_relationships import RoleRelationships
from datadog_api_client.v2.model.roles_type import RolesType

createRoleBody = RoleCreateRequest(
  data=RoleCreateData(
    type=RolesType("roles"),
    attributes=RoleCreateAttributes(
      name="billing-read-role"
    ),
    relationships=RoleRelationships(
      users=None,
      permissions=RelationshipToPermissions(
        data=[
          RelationshipToPermissionData(
            # Billing Read
            id="46a301df-ec5c-11ea-aa9f-970a9ae645e5",
            type=PermissionsType("permissions")
          ),
          RelationshipToPermissionData(
            # Usage Read
            id="46a301e1-ec5c-11ea-aa9f-afa39f6f3e36",
            type=PermissionsType("permissions")
          ),
        ]
      )
    ),
  )
)

def main():
  configuration = Configuration()
  with ApiClient(configuration) as api_client:
    api_instance = RolesApi(api_client)
    try:
      response = api_instance.create_role(body=createRoleBody)
    except Exception as e:
      print(e)
      return
    print(response["data"]["id"])

if __name__ == '__main__':
  main()

実行することでRelationshipToPermissionDataとして記載した権限のついたカスタムロールを作成することができます。API KeyとAPP Keyを入れ替えることで各アカウントに同一のロールを作成することができます。

まとめ

作成したカスタムロールをユーザに付与することで適切に権限を管理することができます。今回はPlan & Usage を管理者以外が見れないことを不便に感じてカスタムロールを作成しました。この記事を読んだ方でこんな感じでカスタムロール使用しているよ〜、こんな感じでロールの管理しているよ〜などあればコメントでご紹介いただきたいです。

ここまで読んでくださりありがとうございました！

*1:Datadog ロールベースのアクセス制御

2022-12-08

AWS Cost Explorer を利用してコストを可視化する

AWS

本記事ではAWSのCost Explorerの使い方を触ったことがない方向けに画像多めに紹介します。

クラウドを利用しているとどうしても月々お金がかかってしまいます。会社で利用しているとなるとお金の報告やら予算の策定やらなにやら、開発とは別のところで苦戦することがあるかもしれません。

私自身も苦戦する中でAWSの費用可視化ツールである Cost Explorer を手探りで利用し、かなり仲良くなりました。せっかく仲良くなったので利用方法をまとめて社内でも使い方勉強会を開催しましたが、勉強会の直後にCost ExplorerのUIにアップデートが入り、資料の画像が古いものとなってしまいました。

本記事では勉強会で行った内容を新UIに対応させて紹介します。

Cost Explorer とは
Cost Explorer へのアクセス方法
トップ画面の見方
Cost Explorerの使い方
Cost Explorer クイズ
- 答え
まとめ

Cost Explorer とは

AWS Cost Explorer の使いやすいインターフェイスでは、AWS のコストと使用量の経時的変化を可視化し、理解しやすい状態で管理できます。すぐに使用開始し、カスタムレポートを作成してコストと使用量のデータを分析できます。大まかにデータを分析することや (例: すべてのアカウントの合計コストと使用量)、コストと使用量のデータを詳細に分析して傾向、コスト要因、異常を特定できます。

aws.amazon.com

Cost Explorer ではAWSのコストを可視化し、簡単な分析まで行うことができます。やれることの幅が広く、最初はどこから触ればいいのか戸惑うかと思います。 1つずつ順番に見ていきましょう。

Cost Explorer へのアクセス方法

まずはCost Explorer にアクセスするところからです。 2種類のアクセス方法があります。

アカウントメニューからアクセス

右上のアカウントメニューから請求ダッシュボードを選択
Cost Management の中から Cost Explorer を選択
Cost Explorerを起動

サーチバーからアクセス

サーチバーに「Cost Explorer」と入れることでアクセスができます。

アクセスできないときは...

Cost Explorer に権限周りでアクセスができない可能性があります。 Cost Explorer にIAMユーザ等でアクセスする場合にはRoot アカウント側でIAM アカウントにアクセスする許可をする必要があります。

詳細なアクセス制御については以下を御覧ください。

docs.aws.amazon.com

アカウントメニューから「アカウント」を選択
IAM ユーザー/ロールによる請求情報へのアクセスの「編集」
「IAM アクセスのアクティブ化」にチェックを入れ「更新」

これでIAM ユーザからもCost Explorer の画面が開けるようになりました。

トップ画面の見方

サマリーのグラフ、金額等が表示されています。下図は何もお金が発生していないアカウントの内容を表示していますが、実際に費用がかかっている場合にはグラフや金額が出てきます。

① Cost Explorer で表示

こちらのリンクからより詳細な分析のできるCost Explorer画面へ移動します。移動先の使い方は後ほど紹介します。

② 傾向

特定のインスタンス、サービスがいくら増えた、全体の金額がいくら増えた、などの情報を表示してくれます。先月との比較が表示されるため月イチで見るのをおすすめします。

③ レポートの表示

Cost Explorerで分析した内容をテンプレートとして保存した「レポート」を作成した際にここに一覧がでてきます。今回の記事ではレポートの作成については触れません。

Cost Explorerの使い方

本編のCost Explorer画面の使い方です。 Cost Explorer の使い方のポイントは大きく分けて下の3つです。

日付範囲の指定
グループ化
フィルタ

これらの項目は「レポートパラメータ」としてグラフの右側に設定項目が表示されています。

① 日付範囲の指定

ここで設定できるのは「日付の粒度」「日付範囲」の2つです。日付の粒度を「月別」として日付範囲を「3か月」とすれば直近3ヶ月の費用変化をグラフとして見れます。

② グループ化

グループ化はとても便利で私のお気に入りの機能です。対象を決めてグラフを詳細化してくれます。グループ化の対象を「グループ化を選択」から選びます。

以下の写真では例として「サービス」でグループ化しました。この場合、月々の利用料のうち、何にいくらかかっているかが詳細にみることができるようになります。大半の費用をこのアカウントではWAFが占めていることがわかります。

他にもリージョンや料金タイプ、インスタンスタイプ、タグなど様々なグループ化が行なえます。

料金タイプでグループ化
- 使用量と税金、その他割引がどれだけ入っていたか確認できる
タグでグループ化
- 特定のタグがついたリソースでグループ化できる
- AWS Organizationsを有効化している場合、親アカウントからグループ化できるタグを指定する必要があります

③ フィルタ

特定のサービスやタグ、インスタンスタイプ等で絞った検索ができます。指定した条件のみを表示、非表示の両パターンでフィルタが可能です。

フィルタタブより「新しいフィルターを追加」
ディメンションにフィルタの対象を指定、
オペレータで表示、非表示を選択
値に何をフィルタするか選択
フィルタを適用

フィルタ機能を用いてグループ化の例で費用の大半を占めていた「WAF」の金額表示を消してみました。

ディメンション	オペレータ	値
サービス	Exclude	WAF

WAF以外の料金がわかるようになりました。特定のサービスのみを見たい場合にはオペレータをInclude にすることで可能です。

料金タイプのフィルタについて

デフォルトで「クレジット」「払い戻し」が除外されています。使用量や支払う金額を見る際には不要なため基本的にはつけたままでOK。

クレジット
- キャンペーン等で得たクレジット分の使用料金
- つい先日AWS re:invent に現地で参加してきてプロモコードを頂いたのでクレジットに金額が表示されるのが楽しみです✌
払い戻し
- 何かしらの理由で返金された分の金額

Cost Explorer クイズ

ここまででCost Explorer マスターとなった皆さんにクイズです。

Cost Explorer上で日毎に見たとき、月初だけやけに費用が高くなっていることがわかります。この原因は何でしょう。

答え

白文字で書いています。選択して読んでください。

月初に税金とリザーブドインスタンスの料金がかかっています。 CostExplorer上は1日にこれら2つの料金が表示されるので月初だけ費用が高く見えます。

確認方法
1. 日付の粒度を「日別」に設定
2. グループ化を「料金タイプ」に設定
3. 「定期的な予約料金」と「Tax」が1日のみにかかっていることがわかります

グループ化を「サービス」にすることでTaxが1日にかかっていることがわかりますがリザーブドインスタンスの料金は「料金タイプ」でグループ化しないとわかりません。

まとめ

簡単にCost Explorerの使い方とポイントとなる3つの機能を紹介しました。 Cost Explorerは機能も多く見え、なかなか取っつきにくい(と自分は思った)ので本記事を参考に触ってみたいと思っていただけたら幸いです。

AWSのコスト管理に手を付けた際、以下の特集がとてもためになったため共有します。 Cost Explorerの使い方以外にも費用体系などまとまっておりおすすめです。

gihyo.jp

2022-03-29

GitHubActionsでプルリクについたコメントを取得しワークフローを分岐させる

GitHub Actions

CIの実行結果をGitHubのプルリクに対してコメントとしてつけると便利です。 CIを走らせるたびに新しいコメントを追記されると大量のコメントが出てきて邪魔なので、marocchino/sticky-pull-request-commentを用いてコメントをアップデートしています。

github.com

やんごとなき理由ですでにコメントされているか、されていないかをもとに分岐したい処理が発生したため特定の文字列を含むコメントがあるかを調べるGitHubActionsのStepを作成しました。

作成

自分がコメントの追加、更新に使用している marocchino/sticky-pull-request-comment はコメントの管理のためにコメントアウトした形で制御用のHeaderをつけます。 がHeaderとして加えられた文字列です。

この文字列を含むコメントがあるか調べるステップを追加します。まずは実際に作成したGitHubActionsファイルを示します。

name: Comment Exist
on: push

jobs:
  CreateComment:
    name: createComment
    runs-on: ubuntu-20.04
    steps:
      - name: Create Comment Hoge
        uses: marocchino/sticky-pull-request-comment@v1
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          header: Hoge
          message: 'Hoge'

      - name: Check Comment Exist
        id: comment_exist
        env:
          HEADER: Hoge
        run: |
          PR_NUM=$(echo ${{ github.ref }} | sed -e 's/[^0-9]//g')
          COMMENT_LISTS=$(curl --request GET \
            --url https://api.github.com/repos/${{ github.repository }}/issues/$PR_NUM/comments \
            --header 'authorization: token ${{ secrets.GITHUB_TOKEN }}' \
            --header 'content-type: application/json' \
            --header 'Accept: application/vnd.github.v3+json')
          EXTRACT=$(echo -E $COMMENT_LISTS \
            | jq -r '.[] | select(.body | contains("<!-- Sticky Pull Request Comment'${HEADER}' -->"))')
          if [ -z "$EXTRACT" ]; then
            echo ::set-output name=exist::false
          else
            echo ::set-output name=exist::true
          fi

      - name: Test
        if: steps.comment_exist.outputs.exist == 'true'
        run: |
          echo 'YES!'

解説

GitHubのAPIを叩いてプルリクについているコメントを一覧で取得、ほしいコメント文字列が含まれているかを調べることで実現しています。

PR_NUM=$(echo ${{ github.ref }} | sed -e 's/[^0-9]//g')で現在のプルリク番号を取得します。 github.refはワークフローを実行するホスト上にデフォルトで設定されている変数でトリガーとなったブランチやタグが記録されます。プルリクをトリガーにした場合プルリク番号は直接入っておらず、refs/pull/2/mergeのような形のためsedコマンドで変換する必要があります。

プルリク番号を取得することでプルリクに紐づくコメントを取得するAPIを利用できます。 GitHubActionsからの実行ならばトークンはデフォルトでsecretsに登録されているためそのまま利用できます。ローカルからcurlする際には設定からトークンを発行しましょう。

curl --request GET \
    --url https://api.github.com/repos/${{ github.repository }}/issues/$PR_NUM/comments \
    --header 'authorization: token ${{ secrets.GITHUB_TOKEN }}' \
    --header 'content-type: application/json' \
    --header 'Accept: application/vnd.github.v3+json'

docs.github.com

取得したコメント一覧のJsonからbodyに目的の文字列が含まれるか調べます。 jq -r '.[] | select(.body | contains("<検索対象文字列>"))' とすることでBodyに目的の文字列が含まれているJsonが抽出できます。このJsonが空か空でないかをもとにecho ::set-output name=exist::trueで出力を作成し、別のステップで出力結果をもとに分岐させます。

正常に動作しているかコメントの存在を確認するステップを増やして確認しました。

まとめ

GitHubActionsかなりいろいろなことができて便利です。もっといいやり方あるよ〜等あればコメントいただけると幸いです。

この記事がどなたかの開発効率の向上につながったら嬉しいです。

概要

費用

構築手順

事前準備

CloudFormationスタックの作成

VPN接続

iPad から接続

環境の削除手順

まとめ

Tips

EC2インスタンスに入って設定を変更したい

AWS-01 Dive deep on Amazon S3

内容のメモ

Amazon Simple Storage Service （S3） とは

フロントエンドの理解

インデックスの理解

ストレージ層の理解

Amazon S3 Express One Zone ストレージクラス

誤削除への対策

感想

AWS-28 大規模クラウドインフラ設計、構築案件の歩き方

内容メモ

設計の骨組みづくり

静的解析について

その他

感想

AWS-57 規模が膨らんで開発スピードが落ちてきたモノリスアプリケーションを正しく分割する方法

内容メモ

Why なぜリアーキテクチャが必要になるのか︖

How どうやってサービスを分割するのか

ドメインモデルの実装方法

感想

まとめ

概要

AWS Systems Manager Automationとは

本ブログで取り上げる内容

実践編 - コンソールからサンプルの runbook を実行する

1. 外部公開された S3 を CloudFormation で作成

2. 作成した外部公開バケットを確認

3. runbook を実行する

4. 実行結果の確認

まとめ

宣伝

そもそもre:invnetとはなにか

事前に知っておいたほうがいい、調べておいたほうがいい編

初めてで海外に不安があるならばツアーに参加するのが良い

事前勉強会が開催される

セッションの予約

情報が集まるSNSをフォローする

準備編

現地でのインターネット

スーツケースには余裕を持たせる

ホテルに給湯器はない

AWSイベントアプリを入れる

移動編

入国審査について

バッジのピックアップ

re:invent現地編

会場について

Keynoteについて

SWAG

EXPO

セッションの参加について

ご飯について

re:play とは

あとがき

更新履歴

Datadogの権限について

カスタムロール

カスタムロールの作り方

カスタムロールの有効化

手動のロールの作成

ロール作成の自動化 with Python

1. 操作するアカウントのAPIキーを取得する

2. Python実行用の環境作成

3. 付与する権限のIDを調べる

4. ロールの作成と権限の付与

まとめ

Cost Explorer とは

Cost Explorer へのアクセス方法

Amazon Simple Storage Service （S3）とは