個人アカウントでも AWS Organizations と IAM Identity Center を使う a.k.a. 古の AWS アカウントにかけられた東京リージョン az-a の呪いからの脱出 - blog.ayakumo.net でも言及しましたが、メンバーアカウントを実験用に使用することは AWS 公式からも推奨しています。気軽に「作って壊せる」がアカウント単位で行えるところがまさにクラウドの真骨頂であるのでこの運用をしない手はありません。
今回は 1 月に作成したメンバーアカウント: playground202401 をクローズしました。手順は AWS Organization から対象となるメンバーアカウントを選択してメニューから Action > Close を実行するだけです。一応、クローズしたメンバーアカウントは 90 日の間はリオープンが可能です。この周期でクォーターごとにメンバーアカウント: playground2024
shuttle.rs を使用して日々の行動を数値化して記録する API を開発しました。体重/体温/歩数といった個人的な数値から、売上/プロジェクトの KPI といったチームで共有したい数値を蓄積して記録した上で、一連のデータを取得することができます。
日々の積み重ねは長期的に個人に大きな変化をもたらします。より望ましい自分となるために、この習慣化を手助けすることが私の個人事業の目標です。習慣化の第一歩として、積み重ねたい行動を記録することはそれ自体が継続を促すという点で価値があります。
開発アルファ版なので認証機能のかわりに自由に発行できるトークンで個人を識別します。また、活動の種類をタグで識別します。クライアントは未実装なため、xh + jq を使用していますが、実装の折には取得した数値を (e)chart.js もしくは R などを使用して可視化することを検討しています。
xh に対して xhs というシンボリックリンクを張ることで HTTPS アクセスが可能になります
➜ echo $(dirname $(which xh))
/Users/kyagi/.cargo/bin
➜ (cd $(dirname $(which xh)) && ln -s ./xh ./xhs)
➜ ls $(dirname $(which xh))/{xh,xhs}
/Users/kyagi/.cargo/bin/xh /Users/kyagi/.cargo/bin/xhs
➜ xhs get -b statscribe.shuttleapp.rs/token | jq -cr .
{"token":"feab32fd-cd48-462c-90d8-80544bc3cc7a"}
➜ xhs post -b statscribe.shuttleapp.rs/stats stat:=77.4 tag=scale token=feab32fd-cd48-462c-90d8-80544bc3cc7a | jq -cr .
{"id":3,"stat":77.4,"tag":"scale","datetime":"2024-07-01T08:54:27.989593+09:00"}
➜ xhs post -b statscribe.shuttleapp.rs/stats stat:=77.1 tag=scale token=feab32fd-cd48-462c-90d8-80544bc3cc7a | jq -cr .
{"id":4,"stat":77.1,"tag":"scale","datetime":"2024-07-01T08:54:36.051251+09:00"}
➜ xhs post -b statscribe.shuttleapp.rs/stats stat:=76.5 tag=scale token=feab32fd-cd48-462c-90d8-80544bc3cc7a | jq -cr .
"feab32fd-cd48-462c-90d8-80544bc3cc7a"}'
{"id":5,"stat":76.5,"tag":"scale","datetime":"2024-07-01T08:54:44.826053+09:00"}
➜ xhs post -b statscribe.shuttleapp.rs/stats stat:=4129 tag=pedometer token=feab32fd-cd48-462c-90d8-80544bc3cc7a | jq -cr .
{"id":6,"stat":4129.0,"tag":"pedometer","datetime":"2024-07-01T08:59:57.811817+09:00"}
➜ xhs get -b statscribe.shuttleapp.rs/stats/feab32fd-cd48-462c-90d8-80544bc3cc7a/all | jq -cr '.[]'
{"id":3,"stat":77.4,"tag":"scale","datetime":"2024-07-01T08:54:27.989593+09:00"}
{"id":4,"stat":77.1,"tag":"sclae","datetime":"2024-07-01T08:54:36.051251+09:00"}
{"id":5,"stat":76.5,"tag":"scale","datetime":"2024-07-01T08:54:44.826053+09:00"}
{"id":6,"stat":4129,"tag":"pedometer","datetime":"2024-07-01T08:59:57.811817+09:00"}
➜ xhs get -b statscribe.shuttleapp.rs/stats/feab32fd-cd48-462c-90d8-80544bc3cc7a/all | jq -cr '.[] | select(.tag == "scale")'
{"id":3,"stat":77.4,"tag":"scale","datetime":"2024-07-01T08:54:27.989593+09:00"}
{"id":4,"stat":77.1,"tag":"scale","datetime":"2024-07-01T08:54:36.051251+09:00"}
{"id":5,"stat":76.5,"tag":"scale","datetime":"2024-07-01T08:54:44.826053+09:00"}
実は Rust で API を作成するのは 2 回目です。前回は actix-web を使用して Zero To Production In Rust を読みながら AWS EC2 のコスト計算 API を開発しました。今回は axum を使用しましたが、作りとしては似ているところが多いような気がしました。ただ以下のような根本的な Rust 力のなさを痛感することになりました。
今回はじめて axum および shuttle.rs が提供しているライブラリ(crate)の shuttle-axum, shuttle-runtime, shuttle-shared-db を使用しました。 shuttle.rs の操作が cargo のサブコマンドとして組み込まれており、開発からデプロイまでの一連の作業をサポートしてくれます。また Github で公開している サンプルプログラム集 も参考になります。
開発用のプラットフォームとしてローカル環境での実行からデプロイまで一通り必要なコマンドは揃っています(例: cargo shuttle run cargo shuttle deploy cargo shuttle resource) 。cargo に組み込まれた shuttle.rs プラットフォームへの操作を通して shuttle.rs を Rust での Web アプリケーション開発におけるエコシステムとして使用することができます。結果的に sqlx を [shuttle.rs]が提供している共用 PostgreSQL を操作するために使用したり axum もより shuttle.rs に合わせた形で使うことになり、積極的にこの敷かれたレールに載ってしまう方が開発効率がよいと感じました。
shuttle.rs のブログでは OpenAI や Amazon Bedrock との連携、さらには Clerk を使用した認証機能の例も紹介されており、全体的にフットワークが軽く新進気鋭な雰囲気を感じることができます。個人的には分散 sqlite3 である Turso と連携できるところが気になっています。
テストの実装と postman を使用したテストに着手します。また認証処理(JWT or Bearer Auth or Clerk) も必要になります。curl + jq では手間となる部分を吸収したクライアントも作成するとより簡単に使えるようになるのかなと考えています。token 保存や tag のタイポ防止、R と連携した合計や平均値の自動出力、(e)chart.js を利用したグラフ化などを通して習慣化をエンパワーメントできればと考えています。
個人開発している Web サービスで決済機能として Stripe を導入予定です。同社の審査は大きく分けて「本人証明」と「ビジネス証明」の 2 つがあり、後者で特商法のページが必要になります。この特商法のページを静的なウェブサイトとして構築するのが本記事の主旨となります。
基本的には S3 の静的ウェブサイト機能 を使用します。ただし、S3 の同機能は HTTPS に対応していないので前段に Cloudfront + Certificate Manager を設置する必要があります。使用する AWS はサービスは以下になります。
| サービス | 用途 | リソースを所有するアカウント | リソースを作成するアカウント | AWS Organizations の OU |
|---|---|---|---|---|
| Route53 | ドメイン取得, DNS 管理 | マネジメントアカウント | メンバーアカウント | OU: Infrastructure/Pord/website-prd |
| S3 | オブジェクトストレージ | マネジメントアカウント | メンバーアカウント | OU: Infrastructure/Pord/website-prd |
| Cloudfront | CDN | マネジメントアカウント | メンバーアカウント | OU: Infrastructure/Pord/website-prd |
| Certificate Manager | SSL 証明書管理 | マネジメントアカウント | メンバーアカウント | OU: Infrastructure/Pord/website-prd |
AWS Organizations のベストプラクティス に則り OU: Infrastructure/Prod/website-prd という メンバーアカウント で構築します。
本来であれば上記のリソースはマネジメントアカウントではなくメンバーアカウントに所有させたかったのですが、構築に AWS から提供されている CloudFormation のテンプレートである amazon-cloudfront-secure-static-site を使用しているため *1 、このような設計としています(ベストプラクティス上はマネジメントアカウントは 同アカウントで必要な最小限のリソースのみを所有するのみにとどめ、ほとんどのリソースはメンバーアカウントが所有する ことが推奨されていますが、これは数少ない例外かもしれません)
今回はメンバーアカウントからマネジメントアカウントの強めの権限を設定した Role に Switch Role して CloudFormation を実行しています。具体的には以下のような設定になります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<account_id_of_member_account>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PrivilegeEscalationToManagementAccountAdministrator",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::<account_id_of_management_account>:role/ManagementAccountAdministrator"
}
]
}
以下は IAM Identity Center で管理している User: kyagi がメンバーアカウント: B の Adminitrator グループからマネジメントアカウント: A の Role: ManagementAccountAdministrator にスイッチした例です。
スイッチ前のマネージメントコンソロールのヘッダです。
スイッチする時のダイアログです。
スイッチ後のマネージメントコンソロールのヘッダです。
S3 を使用した静的ウェブサイト構築については AWS にドキュメントが用意されています。S3 発のドキュメントや Cloudfront 発のドキュメント があります。設定をひとつひとつ確認しながらマニュアルで進めるなら前者ですが、ここでは Cloudformation のテンプレートを紹介している後者を使用しています。
このテンプレートではドメインを取得したアカウントの Route53 から取得した HOSTED ZONE ID を入力として求められます。またリージョンは us-west-1 を想定した実装になっています。私の場合、Route53 のドメイン取得はマネジメントアカウントで管理するようにしているので、ここでは上記で言及したようにメンバーアカウントからマネジメントアカウントに switch role して CloudFormation を実行しています。
一口に、特商法のサイトを構築すると言っても、なかなか手間がかかることがわかりました。今回は AWS から提供されている CloudFormation のテンプレートを使用したのでだいぶ楽でしたが手動で設定する場合はめんどくさそうです。
特商法のサイトに載せるべき主な情報をクラウドサービスに対応させると以下になります。所在地の記載は DMM バーチャルオフィスを契約予定です。
| ID | 項目 | 説明 | 例 | クラウドサービス |
|---|---|---|---|---|
| 1 | 所在地 | 事業所の住所（登記簿上の住所）*個人事業主の場合は「請求があったら遅滞なく開示します」で省略可。 | 〒123-4567 東京都渋谷区○○町○○丁目12-3 | DMM バーチャルオフィス |
| 2 | 電話番号 | 顧客からの日本語の問い合わせに対応できる電話番号*個人事業主の場合は「請求があったら遅滞なく開示します」で省略可。 | 03-1234-5678 受付時間 10:00-18:00（土日祝を除く） | DMM バーチャルオフィス、もしくは、専用のスマフォ + SIM |
| 3 | メールアドレス | 顧客からの問い合わせに対応できるメールアドレス | contact@example..jp | AWS Workmail |
z.enum() にリテラルな文字列の配列を渡すことでその配列のみを有効な入力になるように制限することができます。
(悪いね、今日はカツオ(bonito) は入っていないんだ)
import { z } from 'zod';
const menuAvailableToday = ['tuna', 'mackerel', 'eel', 'squid', 'flounder', 'yellowtail', 'amberjack'];
const orderAcceptable = z.object({
order: z.enum(menuAvailableToday)
});
let yourOrder;
// This passes.
yourOrder = orderAcceptable.parse({ order: 'tuna' });
console.log(`You ordered ${yourOrder.order}`);
// This fails.
// yourOrder = orderAcceptable.parse({ order: 'bonito' });
// console.log(`You ordered ${yourOrder.order}`);
ここでは、期待される特定のファイル名(サイズ + 拡張子)のパターンを生成しています。 TypeScript の標準ライブラリには順列組み合わせの関数が用意されていないようなので、array-combination/src/combination.ts at main · idw111/array-combination · GitHub を使用しています。
z.parse() ではなく z.safeParse() だと型チェックに失敗した時のエラーに応じて処理が可能です。
handle_array_of_literal_string_as_type.ts
import { z } from 'zod';
// https://github.com/idw111/array-combination/blob/main/src/combination.ts
const combination = <T extends any>(...arrays: T[][]): T[][] => {
if (arrays.length === 1) return arrays[0].map((item) => [item]);
const [firstArray, ...restArrays] = arrays;
return combination(...restArrays)
.map((result) => firstArray.map((item) => [item, ...result]))
.flat();
};
const permutations: string[][] = combination(['1040', '700', '460', '300', '200'], ['png', 'jpg', 'jpeg']);
// FIXME: `candidates: string[]` fails with `the error TS2769: No overload matches this call.`
const candidates: any = permutations.map(element => element[0].concat('.', element[1]));
const imageFile = z.object({
fileName: z.enum(candidates)
});
const imf1 = imageFile.parse({ fileName: '1040.png' });
console.log(imf1)
// const imf2 = imageFile.parse({ fileName: '1041.png' });
// console.log(imf2)
ファイル名が所定の組み合わせ以外の場合は ZodError で弾かれます。
➜ node_modules/.bin/tsc handle_array_of_literal_string_as_type.ts --target es2016 --module nodenext --moduleResolution nodenext
➜ node --import tsx handle_array_of_literal_string_as_type.ts
{ fileName: '1040.png' }
/Users/kyagi/lab/skeleton-zod-001/node_modules/zod/lib/types.js:43
const error = new ZodError_1.ZodError(ctx.common.issues);
^
ZodError: [
{
"received": "1041.png",
"code": "invalid_enum_value",
"options": [
"1040.png",
"700.png",
"460.png",
"300.png",
"200.png",
"1040.jpg",
"700.jpg",
"460.jpg",
"300.jpg",
"200.jpg",
"1040.jpeg",
"700.jpeg",
"460.jpeg",
"300.jpeg",
"200.jpeg"
],
"path": [
"fileName"
],
"message": "Invalid enum value. Expected '1040.png' | '700.png' | '460.png' | '300.png' | '200.png' | '1040.jpg' | '700.jpg' | '460.jpg' | '300.jpg' | '200.jpg' | '1040.jpeg' | '700.jpeg' | '460.jpeg' | '300.jpeg' | '200.jpeg', received '1041.png'"
}
]
(... snip ...)
safeParse() の返り値とデータの両方をチェックするテストの例です。
handle_array_of_literal_string_as_type.test.js
import { imageFile } from "./handle_array_of_literal_string_as_type";
describe('1040.png is a valid file name', () => {
const result = imageFile.safeParse({
fileName: "1040.png"
});
test('fileName: 1040.png is OK', () => {
expect(result.success).toBe(true);
});
test('fileName: 1040.png is OK', () => {
expect(result.data.fileName).toBe("1040.png");
});
});
describe('1041.png is NOT a valid file name', () => {
const result = imageFile.safeParse({
fileName: "1041.png"
});
test('fileName: 1041.png is NG', () => {
expect(result.success).toBe(false);
});
});
➜ node_modules/.bin/jest handle_array_of_literal_string_as_type.test.js
PASS ./handle_array_of_literal_string_as_type.test.js
1040.png is a valid file name
✓ fileName: 1040.png is OK (2 ms)
✓ fileName: 1040.png is OK (4 ms)
1041.png is NOT a valid file name
✓ fileName: 1041.png is NG (1 ms)
Test Suites: 1 passed, 1 total
Tests: 3 passed, 3 total
Snapshots: 0 total
Time: 0.698 s, estimated 1 s
Ran all test suites matching /handle_array_of_literal_string_as_type.test.js/i.
昔話になりますが、私は個人の AWS アカウントを 東京リージョンが利用可能になった 2011年 に作成しました。それ以降 EC2 をはじめとして散発的に AWS リソースを使用してきましたが、時代とともに古いアカウントならではの制限事項が目につくようになってきました。
制限事項の中で最も大きいのが 古い AWS アカウントでは東京リージョンのアベイラビリティゾーン a が使用できない という問題です。AWS CDK しかり、Cfn しかり、何かのハンズオンしかり、基本的に新しめの(?) AWS アカウントを想定しており、その度に「他の人のアカウントではうまくいくが自分のアカウントだとエラーになってしまう」ケースが「稀ではなくよくある」事態となっていました。
こういった経緯を含め、アカウント管理の体制を一新して AWS Organizations + IAM Identity Center での運用に切り替えたところ AWS のユーザー体験はかなり向上しました(古いアカウントは管理用のマネジメントアカウントとして残していますが場合によっては削除するかもしれません。また、個人アカウントとは別に同様の管理方法で個人事業向けのアカウントも別口に用意しています。こちらは将来の法人化を見据えたものになります)
複数アカウントでの運用については参考情報にあげたリンクを含めて AWS が豊富なベストプラクティスとガイドラインを出しています。主に AWS Organizations と IAM Identity Center を利用することになります。監査用に Control Tower や AWS Confing を利用してもよいですが個人アカウントでは不要なケースが多いと思います。
ただ、AWS 初心者にとってこれらのベストプラクティスとガイドラインを最初から理解し実装するのはなかなかハードルが高いのではないでしょうか。どちらかというと既に AWS でいくらかの経験があり、リソースや Billing 情報の管理で効率化を図りたい既存ユーザーが複数アカウント運用に切り替えると、ユーザー体験がかなり向上するのではないかと睨んでいます。
AWS で推奨されているベストプラクティスです。AWS ハンズオンを受講した方は一番最初のスライドで「他リソースへの影響を避けるために専用のアカウントを作成することを推奨〜」という断り書きを目にした方も多いと思います。アカウントは「目的ごとにフットワーク軽く作る」ことがプラットフォーム側からも期待されているのです。
| AWS アカウント | アカウントのメールアドレス | AWS Organizations の Organization Unit および配下のメンバーアカウント |
|---|---|---|
| xenogeneic | jsmith+aws+xenogeneic@gmail.com | Management Account |
| adamantine-prod | jsmith+aws+adamantine+workloads+prod@gmail.com | Workloads/Prod/adamantine-prd |
| bomburst-prod | jsmith+aws+bomburst+workloads+prod@gmail.com | Workloads/Prod/bomburst-prd |
| bomburst-dev | jsmith+aws+bomburst+workloads+sdlc+dev@gmail.com | Workloads/SDLC/bomburst-dev |
| handson-20240103 | jsmith+aws+xenogeneic+sandbox+handson-20240103@gmail.com | Sandbox/handson-20240103 |
| xenogeneic-infrastucture | jsmith+aws+xenogeneic+infrastructure+prod@gmail.com | Infrastructure/Prod |
| xenogeneic-security | jsmith+aws+xenogeneic+security+prod@gmail.com | Security/Prod |
※OU: Organization Unit, SDLC: Software Development Life Cycle
IAM Identity Center のポータル経由のログイン例
Sandbox 配下のアカウント運用例
以下は私が個人的に採用している運用上の工夫です。
| Group | Permission Set | Predefined Policies |
|---|---|---|
| Administrators | Administrator | AdministratorAccess |
| SREs | SRE | SystemAdministrator |
| Engineers | Engineer | ReadOnlyAccess (デフォルトはこれで、ここから ABAC で Switch Role させる) |
| BizPeople | BizPerson | Billing |
| Username | Name | Primary Email | Title | Division | Department |
|---|---|---|---|---|---|
| ramuro | Ray Amuro | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+ramuro@gmail.com | sfe | gundam | origin |
| myashima | Mirai Yashima | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+myashima@gmail.com | sre | gundam | origin |
| blinks | Banagher Links | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+blinks@gmail.com | sfe | gundam | unicorn |
| mlzabi | Mineva Lao Zabi | [DefaultEmailAccountBeforeAtMark]+aws+[ProjectName]+mlzabi@gmail.com | salesrep | gundam | unicorn |
※sfe: Software Engineer, sre: site reliability engineer, salesrep: sales representative
aws configure sso を利用して期限付きの credentials 情報を発行したのちに aws cli や SDK を利用します。
~/.aws/cli/cache 配下に期限付きの AWS ACCESS KEY と SECRET ACCESS KEY が発行されキャッシュされた .json が作成されます。またこちらと対になる形で ~/.aws/sso/cache 配下にはセッション情報がキャッシュされた .json が作成されます。結果的に通常の ~/.aws/credentials は不要になります。
➜ aws configure sso
核となるのは JavaScript のライブラリ Apache ECharts です。このライブラリを利用して Canvas API ベースの 2D グラフィックを描画することができます。各言語でのラッパーライブラリが存在し、Rails では rails_charts を利用することで view から簡単に様々なチャートを作成することができます。
Apache ECharts では様々なチャートを描画できますが、カレンダーチャートは Heatmap がベースとなります。Heatmap を拡張したのが Calendar です。描画時に使用可能なオプションもこちらの 2 つから流用できます。
rails_charts の README に従います。Rails7 の場合、編集するファイルは以下の 2 つです。
README 中の Commit.for_calendar_chart の実体は test で使用している ダミーアプリのモデル から確認できます。
適当なカレンダーのデータを与えて描画させた例がこちらです。
➜ cat app/views/home/index.html.erb
<%= calendar_chart(
{
data: [ [Date.new(2023,1,1), 1],
[Date.new(2023,2,2), 5],
[Date.new(2023,3,3), 10],
[Date.new(2023,4,4), 40]
]
},
class: 'box',
options: {
visualMap: {
show: true,
min: 0,
max: 40,
orient: 'horizontal',
inRange: {
color: ['#DAFADA', '#008000']
}
},
calendar: [{
range: '2023',
},]
})
%>
使用しているモデルを created_at と count で「日付 + 数値」に変換し rails_charts で描画することで、日々の活動記録を可視化できます。Github のコミット履歴の活用例は言うに及ばず、継続の度合いを示すインジケーターとして利用の幅は広そうです。日々の勉強や運動、ダイエット記録などにも適用できると思います。
irb(main):013:0> Flashcard.group_by_day(:created_at).count.to_a.last(10)
Flashcard Count (0.8ms) SELECT COUNT(*) AS "count_all", DATE_TRUNC('day', "flashcards"."created_at"::timestamptz AT TIME ZONE 'Etc/UTC')::date AS "date_trunc_day_flashcards_created_at_timestamptz_at_time_zone_e" FROM "flashcards" WHERE ("flashcards"."created_at" IS NOT NULL) GROUP BY DATE_TRUNC('day', "flashcards"."created_at"::timestamptz AT TIME ZONE 'Etc/UTC')::date
=> [[Wed, 06 Dec 2023, 3], [Thu, 07 Dec 2023, 0], [Fri, 08 Dec 2023, 1], [Sat, 09 Dec 2023, 1], [Sun, 10 Dec 2023, 0], [Mon, 11 Dec 2023, 3], [Tue, 12 Dec 2023, 1], [Wed, 13 Dec 2023, 4], [Thu, 14 Dec 2023, 2], [Fri, 15 Dec 2023, 4]]
Google Charts の Calendar Chart と似ていますが関連までは調べていません。
Notion が標準で提供しているテンプレートを物色したところ、Engineering Wiki がとても良かったので紹介します。
ドキュメントをタグごとに group by で集約でき、その結果をタブで切り替えられるので目的のドキュメントを簡単に見つけることができます。また、スペースの利用効率が向上するので、欲しい情報を探してスクロールする必要がなくなります。集約結果の表示方法(ビュー)はリストビューやギャラリビューにすることができるので、ビュー内のソート方法を更新日時にしておくと更新された記事を見分けやすくなります。
ドキュメントにはあらかじめ Verification プロパティが用意されているので、これを利用することでレビュープロセスのワークフローを構築するのがよさそうです。Verification の有効期限を 1 週間後、1 ヶ月後、3 ヶ月後と設定しておくことで定期的なアップデートを促す通知としても活用できます。
API を使用するには Integration を作成した後、右上のハンバーガーメニューから Add Connections を選択して配下のページへのアクセスを許可する必要があります。
試しに Query a database を使ってみましたが、かなり詳細なオブジェクトが返ってきました。Engineering Wiki 自体がひとつのデータベースとなっており識別子として 8a2409b31ac94fcc8269b743e1fb681d が振られています。情報の抽出やバックアップ、自動更新などいろいろな用途がありそうです。
➜ curl -X POST 'https://api.notion.com/v1/databases/8a2409b31ac94fcc8269b743e1fb681d/query' -H 'Authorization: Bearer '"secret_<THIS_IS_SECRET>"'' -H 'Notion-Version: 2022-06-28' -H "Content-Type: application/json" --data '{
"filter": {
"or": [
{
"property": "Tags",
"multi_select": {
"contains": "Codebase"
}
}
]
},
"sorts": [
{
"property": "Page",
"direction": "ascending"
}
]
}' | jq -r '.results[]|select(.object == "page")|.properties.Page.title[].text.content, .url'
Backend
https://www.notion.so/Backend-98ec69babcf545179a8e1bc92bccbbf9
Code Reviews
https://www.notion.so/Code-Reviews-2dc09abb21974f4ba2616fc93517987c
How to QA
https://www.notion.so/How-to-QA-5dd1f96216c84a7cab53c1f50c037c6c
React
https://www.notion.so/React-f9b7185c06a245219768c317ebb804ea
Useful Commands
https://www.notion.so/Useful-Commands-371c609aea5440abb7456d9dfc6e0d8f
ここ数ヶ月 AWS EventBridge を利用した通知フローの改善を通して AWS Observability について、その全体像の理解が深まりました。このエントリでは AWS EventBridge を利用した通知フローについて最近の Input Transformer(w/ Input Path, Input Template) の機能追加も含めてその概要を説明します(抽象的な内容が多くなるので実際に EventBridge の使用経験がないと理解しにくいと思いますがご容赦ください)
結論から言うと CloudWatch Alarm の「生の(加工されない)」通知と、それをイベントとして捕捉して加工した「カスタム」通知の 2 通りをそれぞれの通知チャンネルで管理するのがよいのではないかという設計に辿り着きました。ただ、これはあくまで個人的なベストプラクティスです。EventBridge は AWS の中でも比較的新しいサービスであり 2023年3月に他の AWS サービスからイベントを EventBridge に送信することが可能になり、2023年9月に Input Transformer(w/ Input Path, Input Template) で Chatbot に送る通知内容のカスタマイズが可能になるなど進化を続けているので、現状では AWS 側もベストプラクティスが提供できていない雰囲気を感じています。
上記の図だと 3 段階のインシデントレベル(= sev: severity level) ごとに Slack のチャンネルを用意して以下のように運用するのがよいと考えています(Slack だとチャンネル名は alphabetical にソートされるので最もインシデントレベルが高い 1 が上にくるのもよいと思います)
CloudWatch Alarm にはもともと In Alarm/OK 時に通知する SNS topic を指定することができました。ただ、通知内容のフォーマットを変更することはできず、一部のマークダウンに必要な情報を記載するのみが可能です(日本語もこの一部のマークダウンのみ)。
EventBridge も通知内容のフォーマットを変更することはできなかったのですが、2023/09/12 にリリースされた Input Transformer((w/ Input Path, Input Template)で通知内容を変更することができるようになりました(日本語も可能)。この点、通知内容の柔軟性は EventBridge のほうが上かもしれません。 Custom notifications are now available for AWS Chatbot
(余談ですが、ここでの AWS Chatbot は SNS に対する Subscriber であると同時に Slack に対する Publisher になります。Chatbot は EventBridge > SNS と流れてきたメッセージを Slack の chat.postMessage の API 仕様に基づいて HTTP POST してくれるということです)
CloudWatch Alarm を使用する方法で一般的な通知フローです。
metrics from AWS Service > CloudWatch Alarm > SNS > Chatbot > Slack
EventBridge を使用する方法で補足するイベントパターンを source や detail-type といった属性で絞り込むことができます。Input Template(w/ Input Path, Input Template) を指定して変数に格納した値を通知に載せることも可能です。
events from AWS Service > EventBridge > SNS > Chatbot > Slack events as CloudWatch Alarm State Change > EventBrdige > SNS > Chatbot > Slack
AWS のサービスが発するイベントは Event Structure と呼ばれる共通の json フォーマットの仕様に基づいています。EventBridge で補足するイベントは Source に対象の AWS サービスを指定した後に detail でそれぞれのサービスの持つ固有のパラメータで絞り込むことができます。
例として特定の ElastiCache for Redis のクラスタのイベントを補足するイベントパターンは以下になります。ここで readOnly はイベントが read 系(List, Get, Describe) かそうでないかを表しています。フェイルオーバーなどのイベントは readOnly: false になるのでリソースに何かしらの状態遷移が発生した場合を補足する際に役立ちます。readOnly に似た属性に managementEvent があります。ただもともとデフォルトで read 系のイベントは EventBridge には送られない仕様 となっています。これは AWS Management Console や CLI で状態を確認するための処理、つまり状態遷移が発生しない状態を、わざわざイベントとして処理する必要がないからだと思われます。
{
"source": ["aws.elasticache"],
"detail": {
"eventSource": ["elasticache.amazonaws.com"],
"requestParameters": {
"replicationGroupId": ["my-elasticache-dev"]
},
"readOnly": [false]
}
これらのイベントは CloudWatch LogGroup をイベントして補足するように設定した後、CloudWatch LogGroup のログを見るのが手っ取り早く確認できます。EventBridge の Input Transformer(w/ Input Path, Input Template) でも CloudWatch LogGroup のログをコピー&ペーストできるようになっているので便利です。なので EventBridge の Rule を作成する場合はまずは Target に SNS Topic ではなく CloudWatch LogGroup を指定して対象の AWS サービスのイベントログの json を吐き出させて、後々の Rule で Input Transformer のフォームに貼り付けるのが有用です。
ひとつ面白いイベントパターンとしては CloudWatch Alarm State Change をイベントして補足できることです(ややこしいのですが「アラームの状態が変化したというイベント」になります)。これを利用すると CloudWatch Alarm が Alarm/OK/Insufficient data といった状態遷移が発生した時にメトリクス経由の通知とイベント経由の通知の 2 種類で通知を飛ばすことが可能になります。2 種類通知が飛ぶのは冗長なので冒頭に挙げた人間が読む用のチャンネル(イベントベース)と生の通知用のチャンネル(メトリクスベース) の 2 つにわけるとよいと思います。
{
"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"]
}
また CloudTrail の監視もイベントとして処理できるので監査プロセスにも使用できます。
{
"source" : [ "aws.sts" ],
"detail-type": ["AWS API Call via CloudTrail"],
"detail" : {
"eventName" : ["AssumeRole"]
}
}
EventBridge はもともと CloudWatch Events という名称で CloudWatch の機能の一部として提供されていました。今では機能の拡充や他サービスとの繋ぎ込みによって独立したサービスとなり名称も EventBridge となっています。ただ AWS Management Console の CloudWatch 画面からは EventBridge のリンクが残っておりその名残を感じさせます(TV の歴史番組みたいになってきたな)。
| 時系列 | メトリクスレポジトリの名称および説明 | イベントレポジトリ名称および説明 |
|---|---|---|
| 昔 | CloudWatch: a metrics repository | CloudWatch Events: eventbuses |
| 今 | CloudWatch: a metrics repository | EventBridge: eventbuses and pipes(receive events and delivers to zero or more targets) |
メトリクスとイベントの管理体系を分けた理由はなんでしょうか。個人的には常に発生するメトリクスといつ発生するかわからないイベントの性質の違いからではないかと推察しています。
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-21_Observe_and_detect_for_application_availability_and_performance_KMD05-KMD13.pdf docs.aws.amazon.com Custom notifications are now available for AWS Chatbotaws.amazon.com docs.aws.amazon.com
docker buildx でマルチプラットフォームのイメージを作成する - blog.ayakumo.net で紹介した buildx を利用して amd64 と arm64 のイメージを作成していきます。環境は以下になります。
Docker ドキュメンテーションの Building multi-platform images を参考に 3 つのステップごとに実行していきます。
You can build multi-platform images using three different strategies that are supported by Buildx and Dockerfiles:
- Using the QEMU emulation support in the kernel
- Building on multiple native nodes using the same builder instance
- Using a stage in Dockerfile to cross-compile to different architectures
➜ docker run --privileged --rm tonistiigi/binfmt --install all
ここでは Docker のドキュメンテーションに倣ってビルダーインスタンスの名前を mybuilder としていますが intel-and-arm-builder など出力先のプラットフォームがわかる名前にしてもよいかもしれません。
➜ docker buildx create --name mybuilder --driver docker-container --bootstrap [+] Building 3.0s (1/1) FINISHED => [internal] booting buildkit 3.0s => => pulling image moby/buildkit:buildx-stable-1 2.2s => => creating container buildx_buildkit_mybuilder0 0.8s mybuilder ➜ docker buildx use mybuilder ➜ docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS BUILDKIT PLATFORMS mybuilder * docker-container mybuilder0 unix:///var/run/docker.sock running v0.11.6 linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6 default docker default default running 20.10.24 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 desktop-linux docker desktop-linux desktop-linux running 20.10.24 linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7, linux/arm/v6 ➜ docker buildx inspect Name: mybuilder Driver: docker-container Last Activity: 2023-05-13 06:25:09 +0000 UTC Nodes: Name: mybuilder0 Endpoint: unix:///var/run/docker.sock Status: running Buildkit: v0.11.6 Platforms: linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64, linux/arm/v7, linux/arm/v6
該当コミットはこちらになります: https://github.com/kyagi/ec5/commit/b5bf4488d130e539743eca265b027b43fd5eb9bb
➜ vi Dockerfile
➜ docker buildx build --platform linux/amd64,linux/arm64 .
Dockerfile で echo しているメッセージが対象プラットフォームごとに出力されるのでわかりやすいですね。
このままだとコンテナイメージはキャッシュされるだけでコンテナレジストリには登録されないため --push でレジストリに送ります。
➜ docker buildx build --platform linux/amd64,linux/arm64 -t kyagi/ec5:latest --push .
コンテナレジストリ上で amd64, arm64 の両方のイメージが格納されていることを確認できました。
AWS EC2 のコスト計算 API を Rust で作成した - blog.ayakumo.net で紹介したツールの README を作成するにあたり asciinema と agg*1 を使用しています。ターミナルセッションを GIF にすることで、ツールの動作や実行環境が読み手にわかりやすくなります。もともとは https://github.com/ducaale/xh の README で使用されていたのを見たのがきっかけで、今回、自分のツールでも採用してみました。:-)
asciinema rec で録画用のターミナルセッションを開始すると新たに bash が起動されるので録画したいコマンドを打ちこんでいきます。➜ asciinema rec (... snip ...)
exit で録画を終了します。そのまま asciinema.org に .cast ファイルをアップロードするかローカルに保存するかを選択します。保存した .cast ファイルは asciinema play で再生します。ローカルで保存した .cast を後から asciinema upload でアップロードすることも可能です。➜ exit asciinema: recording finished asciinema: press <enter> to upload to asciinema.org, <ctrl-c> to save locally asciinema: asciicast saved to /var/folders/yr/f0mycbg912b6hjt6tbrkh9j80000gn/T/tmpj433lze8-ascii.cast ➜ asciinema play /var/folders/yr/f0mycbg912b6hjt6tbrkh9j80000gn/T/tmpj433lze8-ascii.cast
➜ asciinema upload /var/folders/yr/f0mycbg912b6hjt6tbrkh9j80000gn/T/tmpj433lze8-ascii.cast
➜ agg --theme monokai --font-size 20 --speed 2 /var/folders/yr/f0mycbg912b6hjt6tbrkh9j80000gn/T/tmpj433lze8-ascii.cast ~/Desktop/ec5-demo.gif
起動と終了は古のscript コマンドと同じです。打ち込むコマンドをタイピングしている最中にミスしてしまうとちょっと恥ずかしいのでコピペにするか、もしくはゆっくりでもいいので確実に入力していきます。.gif にする場合は agg を使用して再生速度を変更可能なので、確実に入力していったほうが最終的な見栄えはよくなると思います。
ターミナル操作を動画にしておくのはソフトウェア開発のいろいろな場面で有用だと思うので活用していきたいと考えています。プロジェクトで使う場合はプライベートに .cast を保存して共有するのがよいかもしれません。ただ、基本的に 一時停止ができないので複雑な操作をする場合は QuickTime などを利用して .mov のほうがいいでしょうか...
*1:agg はもともと asciicast2gif という名前で開発されていたようです
