2024-06-04

AWS CDK でプレフィックス集計のために Amazon S3 Storage Lens を設定する

Amazon S3 でオブジェクトの使用状況（合計サイズ・平均サイズなど）を「プレフィックス別（フォルダ別）」で可視化する場合，Amazon S3 Storage Lens の「高度なメトリクスとレコメンデーション機能」で「プレフィックス集計」を設定する❗️

docs.aws.amazon.com

今回は AWS CDK で aws_s3.CfnStorageLens を使って「プレフィックス集計」を設定してみた．設定の詳細な仕様は AWS CloudFormation ドキュメント参照📝

そして，Amazon S3 Storage Lens の設定をシンプルにするため

集計するプレフィックスの階層は 1
集計対象にするプレフィックスの最小サイズ閾値は 1%（設定できる最低値）
集計対象は新しく作った Amazon S3 バケットに限定

とした👌

docs.aws.amazon.com

サンプルコードを載せておく．ちなみに検証で使った kakakakakku-sandbox-storage-lens バケットは既に削除してある🗑

import {
  Stack,
  StackProps,
  aws_s3,
} from 'aws-cdk-lib'
import { Construct } from 'constructs'

export class SandboxCdkS3Stack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props)

    const bucket = new aws_s3.Bucket(this, 'Bucket', {
      bucketName: 'kakakakakku-sandbox-storage-lens',
    })

    new aws_s3.CfnStorageLens(this, 'StorageLens', {
      storageLensConfiguration: {
        id: 'storage-lens',
        isEnabled: true,
        accountLevel: {
          bucketLevel: {
            prefixLevel: {
              storageMetrics: {
                selectionCriteria: {
                  delimiter: '/',
                  maxDepth: 1,
                  minStorageBytesPercentage: 1,
                }
              }
            }
          }
        },
        include: {
          buckets: [
            bucket.bucketArn
          ]
        }
      }
    })
  }
}

そして prefix-1 から prefix-5 までのフォルダにサンプルファイルをアップロードして，数日待ったらプレフィックス別の使用状況を確認できるようになっていた👏

prefix-1/
prefix-2/
prefix-3/
prefix-4/
prefix-5/

以下にプレフィックス集計結果の一部を載せておく👀

2024-05-30

テスタビリティ（テスト容易性）に関してチームで考えるエクササイズがたくさん！Team Guide to Software Testability を読んだ

本

ソフトウェアのテスタビリティ（テスト容易性）に関してまとまった書籍「Team Guide to Software Testability」を読んだ📕

本書の特徴は「テスタビリティ」を重要視してソフトウェアの品質・デリバリーの予測可能性を高めていくために「どのようにチームで取り組んでいくか」というチーム目線で技術的な施策と組織的な施策が紹介されている点かなと💡後述するエクササイズも充実していて，読んで良かったな〜と思える一冊だった．テスタビリティに含まれる品質特性に関しては優れたテスト容易性を実現するためのポイント | PrAhaENGINEERLAB に詳しくまとまっていて，あわせて読むと相乗効果があると思う📝

Team Guide to Software Testability: Better software through greater testability (Team Guides for Software Book 3) (English Edition)

作者:Winter, Ash,Meaney, Rob
Conflux Books

Amazon

本書は Team Guide というシリーズで計4種類出版されていて，他のテーマも気になるぞー＼( 'ω')／ちなみに Leanpub だと4冊セットで安く買えたりもする👌

Team Guide to Software Operability
Team Guide to Metrics for Business Decisions
Team Guide to Software Testability
Team Guide to Software Releasability

leanpub.com

最近ソフトウェアのテスト全般に課題のあるプロダクトを支援していて，参考になる情報をインプットする中で Team Guide to Software Testability が良さそうだったので読むことにしたという経緯がある💡ちなみに Team Guide to Software Testability は「Web API テスト技法」を読んでいたら第7章で紹介されていて知った．

Web APIテスト技法

作者:Mark Winteringham
翔泳社

Amazon

Exercises
Introduction
1: Set a pragmatic direction for improving testability using trade-off sliders
2: Create testability targets to improve interactions with dependencies
3: Adopt testability mapping to expose hard-to-test architectures
4: Apply the CODS model to increase architectural testability for faster feedback
5: Adopt ephemeral development environments for fast feedback
6: Use production data to enhance your testing strategy
7: Use team testing reviews to enable sustainable delivery
Appendix - Notes on 10 P’s of Testability

テスタビリティの重要さ

Introduction ではテスタビリティの重要さがコンパクトにまとまっていた．テスタビリティの価値を再確認できて良かった👌

Team dynamics（チームのダイナミクス）
Predictability（予測可能性）
Supporting your business and customers（ビジネスと顧客のサポート）
Fast feedback（迅速なフィードバック）
Data, not opinion（意見ではなくデータ）

本書は TDD (Test-Driven Development) と直接的な関係があるわけではないけど，TDD はテスタビリティを意識する機会になると思うし，Fast feedback に関しては fukabori.fm #114 で話題に出ていたフィードバックの話にもつながるな〜と思いながら読んでいた📻

fukabori.fm

エクササイズ

本書の良いところは，テスタビリティに関する解説だけでなく，各章に「エクササイズ」というチームで取り組むイベントが紹介されていること❗️エクササイズの内容以外に「準備すること・ファシリテーションのコツ・FAQ・ゴール・アウトプット」などもまとまっていて，取り組みやすいようになっていた．

特にエクササイズに取り組むことを考えると「ファシリテーションの良し悪し」で効果が全然変わってきそうで重要だと感じた．

Chapter 1 exercises
- Team Test for Testability
  - 1.2 Exercise: do the Team Test for Testability for a quick testability health check
- Trade Off Sliders
  - 1.3 Exercise: use Trade-Off Sliders to guide your testability focus
Chapter 2 exercises
- Testability Dependency Targets
  - 2.2 Exercise: employ Testability Dependency Targets to improve interactions with dependent teams and systems
Chapter 3 exercises
- Testing Smells
  - 3.3 Exercise: Use testing smells to diagnose poor architectural testability
- Testability Mapping
  - 3.4 Exercise: adopt testability mapping to measure testing feedback and waste
Chapter 4 exercises
- CODS model
  - 4.3 Exercise: Use ‘CODS’ to increase architectural testability
Chapter 5 exercises
- Agile Test Quadrants
  - 5.3 Exercise: Use the Agile Test Quadrants to extend testing in your development environment
Chapter 6 exercises
- Data from Production
  - 6.2 Exercise: employ data from production to keep your test strategy relevant
Chapter 7 exercises
- 10 P’s of Testability
  - 7.3 Exercise: use the 10 P’s of Testability to track team testing culture
- Incident Reviews
  - 7.4 Exercise: adopt incident reviews to target testability improvement actions

どのエクササイズも良かったけど，特に良くてすぐに取り組んでみようと思った2つを紹介する👏

Testing Smells

このエクササイズでは以下の「15項目の課題」に対して，どれがテスタビリティの非効率さに影響を与えているのかを洗い出す．

Too many production issues（運用上の問題が多すぎる）
Pre-release regression cycles（リリース前に行う回帰テストのサイクル）
Lack of automation & exploratory testing（自動化と探索的テストが不足している）
Hesitance to change code（コード変更に対する躊躇）
Testing not considered during architectural design（アーキテクチャ設計時にテストが考慮されていない）
Team constantly seeking more testers（チームが常にテスト担当者を探している）
Too many slow user interface tests（UI テストが遅すぎる）
Important scenarios not tested（重要なシナリオがテストされていない）
Ineffective unit and integration tests（非効率な単体テストと統合テスト）
Cluttered, ineffective logging（適当で非効率なログ）
Flaky nondeterministic automation（不安定な自動化）
Tests that contain duplication & irrelevant detail（重複しているテストと不要なテスト）
Issues are difficult to reproduce（再現できない問題）
Issues are difficult to isolate & debug（問題を切り分けてデバッグできない問題）
Too much effort spent writing, maintaining and debugging automation（自動化のメンテナンスとデバッグが大変すぎる）

そして，それぞれの項目に対して以下の 1-5 のスコアを付ける．最終的にチームで優先的に取り組むべき（取り除くべき）課題のトップ3を洗い出して，ディスカッションをする❗️

1: No impact on team effectiveness（チームの効率さに影響なし）
2: Small impact on team effectiveness（チームの効率さに少し影響がある）
3: Moderate impact but rarely impacts team effectiveness（ある程度の影響はあるがチームの効率さにはほとんど影響なし）
4: Moderate impact but often impacts team effectiveness（ある程度の影響がありチームの効率さにも頻繁に影響がある）
5: Large impact, almost always impacts team effectiveness（影響が大きく常にチームの効率さに影響がある）

10 P’s of Testability

このエクササイズでは以下の「10項目の観点」に対して，どれがテスタビリティに悪い影響を与えているのかを洗い出す．

People（人々）
Philosophy（行動指針）
Product（プロダクト）
Process（プロセス）
Problem（問題）
Project（プロジェクト）
Pipeline（パイプライン）
Productivity（生産性）
Production Issues（本番環境の課題）
Proactivity（積極性）

そして，それぞれの項目に対して以下の3種類から投票する．最終的にテスタビリティに悪い影響を与えている項目を洗い出して，改善策をディスカッションする❗️

happy（満足）
unhappy（不満）
no opinion（意見なし）

「テスタビリティに課題がある」と言っても，チームによって原因は違っていて，さらにメンバー間の価値観の違いなどもあるため，テスタビリティに対する認識合わせができることは重要だと思う．よって，このエクササイズはすぐにでも取り組みたいと思った💪例えば四半期ごとに実施すればテスタビリティの変化を計測できるというメリットもあると思う．

まとめ

「Team Guide to Software Testability」を読んだ📕読んで終わりではなく，実際にチームでエクササイズに取り組むことでさらに効果が得られる一冊だった．ソフトウェアのテスタビリティ（テスト容易性）に課題を感じていたら読んでみると良いのではないでしょうか〜＼( 'ω')／

Team Guide to Software Testability: Better software through greater testability (Team Guides for Software Book 3) (English Edition)

作者:Winter, Ash,Meaney, Rob
Conflux Books

Amazon

Terraform の AWS Cloud Control Provider (awscc) で Amazon Inspector「抑制ルール」を設定しよう

Terraform AWS Inspector

現時点（2024年5月）だと Terraform AWS Provider では Amazon Inspector の「抑制ルール」を設定できないという制約がある💦

github.com

Terraform AWS Provider 以外だと

マネジメントコンソール
AWS CLI（参考: AWS CLI で Amazon Inspector「抑制ルール」を設定する - kakakakakku blog）
AWS CloudFormation

を使って Amazon Inspector の「抑制ルール」を設定することもできるけど，AWS Cloud Control Provider (awscc) の inspectorv2_filter リソースを使って設定することもできる❗️今回はサンプルとして Amazon Linux 2023 Security Advisories に載っている CVE を適当にピックアップして抑制してみた．

resource "awscc_inspectorv2_filter" "suppression" {
  name          = "cve-suppression-awscc"
  filter_action = "SUPPRESS"
  filter_criteria = {
    vulnerability_id = [
      {
        comparison = "EQUALS"
        value      = "CVE-2022-41723"
      },
      {
        comparison = "EQUALS"
        value      = "CVE-2023-39326"
      },
      {
        comparison = "EQUALS"
        value      = "CVE-2023-6597"
      },
    ]
  }
}

簡単👌

前に AWS Chatbot を AWS Cloud Control Provider (awscc) で構築するのも試した🤖

kakakakakku.hatenablog.com

2024-05-28

AWS CLI で Amazon Inspector「抑制ルール」を設定する

AWS Inspector

Amazon Inspector の「抑制ルール (suppression rules)」を使うと，条件に一致する検出結果を除外できる．また Amazon Inspector では FindingStatus: SUPPRESSED として AWS Security Hub に検出結果を統合するため，過剰に増えてしまう AWS Security Hub 側の通知を減らすこともできる👌

docs.aws.amazon.com

今回は Amazon Inspector の「抑制ルール」を AWS CLI で設定してみた❗️

`aws inspector2 create-filter` コマンド

aws inspector2 create-filter コマンドを使って設定できる．

awscli.amazonaws.com

今回はサンプルとして Amazon Linux 2023 Security Advisories に載っている CVE を適当にピックアップして抑制する．注意点としては vulnerabilityId に設定できる CVE は API (FilterCriteria) 側で「最大10個まで」という仕様になっているところ．多くの CVE を抑制する場合は複数の抑制ルールを設定する必要がある📝（それはもう根本的な対応が必要な状況にも感じるけど...😇）

$ aws inspector2 create-filter \
  --name cve-suppression \
  --action SUPPRESS \
  --filter-criteria '{
    "vulnerabilityId": [
      {"comparison": "EQUALS", "value": "CVE-2022-41723"},
      {"comparison": "EQUALS", "value": "CVE-2023-39326"},
      {"comparison": "EQUALS", "value": "CVE-2023-6597"}
    ]
  }'
{
    "arn": "arn:aws:inspector2:ap-northeast-1:111111111111:owner/111111111111/filter/f1e2c67b2501b7b1"
}

`aws inspector2 update-filter` コマンド

aws inspector2 update-filter コマンドを使って更新できる．更新するときは --filter-arn オプションに ARN を指定することを忘れずに👍

$ aws inspector2 update-filter \
  --filter-arn arn:aws:inspector2:ap-northeast-1:111111111111:owner/111111111111/filter/f1e2c67b2501b7b1 \
  --filter-criteria '{
    "vulnerabilityId": [
      {"comparison": "EQUALS", "value": "CVE-2022-41723"},
      {"comparison": "EQUALS", "value": "CVE-2023-39326"},
      {"comparison": "EQUALS", "value": "CVE-2023-6597"},
      {"comparison": "EQUALS", "value": "CVE-2024-20290"},
      {"comparison": "EQUALS", "value": "CVE-2024-21506"}
    ]
  }'
{
    "arn": "arn:aws:inspector2:ap-northeast-1:111111111111:owner/111111111111/filter/f1e2c67b2501b7b1"
}

Terraform AWS Provider サポート外

現時点（2024年5月）だと Terraform AWS Provider では Amazon Inspector の抑制ルールを設定できないという制約がある💦

github.com

2024-05-27

React-Admin を1時間で速習できる！React-Admin Tutorial

React-Admin

React-Admin を使うことになるかもしれず，今まで使ったことがなかったので，まずは「React-Admin Tutorial」を試してみた❗️React-Admin を使ったフロントエンドの実装と基本的な仕組みを速習できて良かった💡おすすめ＼( 'ω')／

ちなみに 30 minutes tutorial って書いてあるのは速すぎると思う😅コードを読みながら進めたり，気になった部分をドキュメントで調べながらだと普通に1時間以上かかった〜

marmelab.com

React-Admin Tutorial 実施ログ

React-Admin Tutorial の実施ログを抜粋してまとめておく📝

まず，npm init react-admin test-admin コマンドを実行してプロジェクトをセットアップする．そして npm run dev コマンドを実行すると，すぐに React-Admin の初期画面が表示できる👌

React-Admin Tutorial ではバックエンド API として JSONPlaceholder の /users API と /posts API を使う．

jsonplaceholder.typicode.com

セットアップ時にデータプロバイダーも作られていて，すぐに API を呼び出せる．そして動作確認用の ListGuesser コンポーネントを追加したら，すぐに Users 一覧画面を実装できた．その後は Datagrid コンポーネントなどを使って一覧画面をカスタマイズしていく❗️

marmelab.com

次に Posts 一覧画面を実装するときに ReferenceField コンポーネントが出てくる📝簡単に言うとリソース間の参照をしてくれて，今回だと Posts.user_id を Users.id に紐付けてくれる🔗 便利だ〜

marmelab.com

そして Create コンポーネントと SimpleForm コンポーネントを使って Posts 登録画面も簡単に実装できた．ちなみに React-Admin では「楽観的アップデート (optimistic updates)」という仕組みがあって，Save ボタンを押してから数秒後に API が呼び出されると書いてあった💡そして数秒以内であれば取り消すこともできる．Gmail の 元に戻す に似てる〜

marmelab.com

後半では Posts 一覧画面に検索とフィルタを実装したりもする🔎

終盤ではログイン画面も作る🔑今回は localStorage に設定する超簡易的な仕組みだけど，React-Admin には Auth0 / Amazon Cognito などの Auth Provider もあるから柔軟に実装できそう．

marmelab.com

まとめ

「React-Admin Tutorial」は1時間ぐらいで React-Admin を速習できる素晴らしいコンテンツだった❗️基本は理解できたので，あとは他のドキュメントも読みつつ実装していこうと思う．ちなみにドキュメントに Beginner Mode というトグルがあるのもよく考えられていて良いな〜と思った👏