Quantcast
Channel: kakakakakku blog
Viewing all 903 articles
Browse latest View live

Terraform で無料利用枠の VPC IP Address Manager (IPAM) を設定する

$
0
0

2023年11月から VPC IP Address Manager (IPAM)「無料枠利用枠」が追加されて Public IP Insightsなどの機能が無料で使えるようになった💡そして,2024年2月から課金対象になった IPv4 の最適化のために Public IP Insights を使いたいという場面もあると思う.

aws.amazon.com

aws.amazon.com

Terraform で試す

実は Terraform AWS Provider では今まで aws_vpc_ipamtierはサポートされていなかった.今日(2024年3月29日)にリリースされた v5.43.0でついにサポートされた❗️待ってました〜 \( 'ω')/

github.com

👾 ipam.tf

設定自体は簡単で aws_vpc_ipamtier = "free"を追加すれば OK👌デフォルトは advancedなので注意しておくと良さそう.あと今回は operating_regionsにバージニア北部リージョンを設定した💡もちろん複数リージョンを設定することもできる.

resource"aws_vpc_ipam""main"{tier = "free"operating_regions{region_name = "us-east-1"}}

関連記事

AWS CDK で VPC IP Address Manager (IPAM)を設定する記事は過去に書いているので参考まで〜📝

kakakakakku.hatenablog.com


pytest の capsys で stdout(標準出力)と stderr(標準エラー)をテストする

$
0
0

pytest の capsysを使うと Python スクリプトで出力する stdout(標準出力)と stderr(標準エラー)をテストできる❗️関数の実行結果ではなく,その途中に出力するログに着目したい場面もあって便利〜 \( 'ω')/

docs.pytest.org

👾 src/app.py

hello()関数は HelloWorld!を stdout と stderr に出力して,version()関数は Python バージョンを stdout に出力する.サンプルコードなので特に意味はないけど今回はこの関数をテスト対象にする💡

import platform
import sys


defhello():
    print('Hello')
    print('World!', file=sys.stderr)


defversion():
    print(platform.python_version())

👾 tests/test_app.py

テストコードでは capsys.readouterr()を使って stdout と stderr を取得して簡単に assert できる👌

from app import hello, version


deftest_main(capsys):
    hello()
    captured = capsys.readouterr()
    assert captured.out == 'Hello\n'assert captured.err == 'World!\n'deftest_version(capsys):
    version()
    captured = capsys.readouterr()
    assert captured.out == '3.12.2\n'

テスト実行

テストできた👌

$ pytest .
=====================================================test session starts =====================================================(中略)
configfile: pytest.ini
collected 2 items

tests/test_app.py ..                                                                                                    [100%]======================================================2 passed in0.01s ======================================================

参考資料

capsys「テスト駆動 Python 第2版」の CHAPTER 4 にも載ってた📕

自信を持って pytest を活用するためのノウハウが凝縮された「テスト駆動 Python 第2版」を読んだ

$
0
0

「テスト駆動 Python 第2版」を読んだ📕

仕事で pytestを使ってて,もっと自信を持って書けるようになりたいな〜と思っていたら本書を見つけてさっそく読んでみた.pytest の機能・記法・設定・Tips などの理解が深まって本当に読んで良かった❗️フィクスチャ・パラメータ化・モック・プラグイン活用など,今まで何となく書いてたところを自信を持って書けるようになって,仕事で pytest を書くのが楽しくなった🦄

もちろん pytest の公式ドキュメントを読むべきだし,本書の内容の多くは公式ドキュメントにも載っているとは思うけど,本書の翻訳はとても読みやすく,pytest の全体像をサッと把握できて,また Cards というサンプルアプリケーションを題材に実際に pytest を試しながら読み進められるから本書を読む価値はあると思う.個人的には本当に読んで良かったな〜と感じてる👍

docs.pytest.org

目次

目次をザッと見て,気になる Chapter があったら読んでみると良いかと👌

  • Part.1: pytest の主力機能
    • Chapter.1: はじめての pytest
    • Chapter.2: テスト関数を書く
    • Chapter.3: pytest のフィクスチャ
    • Chapter.4: 組み込みフィクスチャ
    • Chapter.5: パラメータ化
    • Chapter.6: マーカー
  • Part.2: プロジェクトに取り組む
    • Chapter.7: 戦略
    • Chapter.8: 設定ファイル
    • Chapter.9: カバレッジ
    • Chapter.10: モック
    • Chapter.11: tox と継続的インテグレーション
    • Chapter.12: スクリプトとアプリケーションのテスト
    • Chapter.13: テストの失敗をデバッグする
  • Part.3: ブースターロケット
    • Chapter.14: サードパーティプラグイン
    • Chapter.15: プラグインの作成
    • Chapter.16: 高度なパラメータ化

本書で使う Cards アプリケーションのコードは原著サイトから ZIP でダウンロードできる.

pragprog.com

Chapter.4

pytest で一時的なディレクトリを作れる組み込みフィクスチャ tmp_path(function スコープ)と tmp_path_factory(session スコープ)はさっそく使えそうだった.

docs.pytest.org

他にも Chapter.4 で紹介されてた組み込みフィクスチャは便利で capsysは別途試して簡単にまとめた.

kakakakakku.hatenablog.com

Chapter.8

pytest.initestpathsを設定するのは明確にはなるけど冗長だよなぁ〜と思っていたらtestpathsを指定しておくと pytest 開始時の時間を少し節約できる」と書いてあって発見だった👀ある程度プロジェクトの規模が大きくないと差は出なさそうではあるけど知れて良かった情報の一つだった👍

[pytest]
testpaths = tests

docs.pytest.org

Chapter.12

スクリプトとテストコードを srcディレクトリと testsディレクトリに分割したら import できずにハマるというのはよくあると思う💨僕自身も最初ハマって先輩に相談して教えてもらった経緯もあったりする.本書の第2版では Chapter.12 に Python の検索パスの解説が追加されていて良かった❗️本書を読んで pytest の import にハマる人が減ると良いなぁ〜 \( 'ω')/

.
├── pytest.ini
├── src
│   └── hello.py
└── tests
    └── test_hello.py

本書では pytest.inipythonpathを設定する例が紹介されていた.

[pytest]
pythonpath = src

もちろん pytest.iniではなく pyproject.tomlに設定することもできる👌

[tool.pytest.ini_options]
pythonpath = "src"

Chapter.14

pytest プラグインは今までほとんど活用できてなかった💨 pytest サイトの Plugin Listを見ながら気になったプラグインをさっそく導入してみて便利❗️

github.com

github.com

github.com

github.com

Chapter.16

@pytest.mark.parametrizeでパラメータ化するのは普段から使っているけど,ididsにテスト識別子を設定するという Tips は今まで活用できてなかった.確かにパラメータ化したテストで失敗すると判別しにくく感じるときもあった.さっそく仕事でも使うようにした👌

docs.pytest.org

その他

他に読書メモに残したことを箇条書きにしておく❗️

  • pytest --setup-showでフィクスチャの実行順をログに出力できる
  • pytest --tb=noでテスト失敗時のトレースバックを非表示にできる
  • pytest --showlocalsでテスト失敗時にローカル変数を表示できる
  • conftest.pyでフィクスチャを共有できる
  • @pytest.fixtureの名前を変更できる
  • requestsをモックできる Responsesが便利そう

誤植

出版社サイトに掲載されていない誤植を見つけたのでメモしておく📝

  • P.120: 対処できるしょうか。対処できるでしょうか。
  • P.122: 簡単かかもしれないが簡単かもしれないが

www.shoeisha.co.jp

X ポスト🔗

GitHub Actions でワークフローの同時実行を防ぐ concurrency 設定

$
0
0

GitHub Actions ではデフォルトの挙動として同じワークフローの複数のジョブを同時実行できる.無駄に待つ必要がないという意味ではメリットがあるけど,ワークフローによっては同時実行したくないこともあると思う.

GitHub Actions でワークフローが複数トリガーされてしまって慌てて止めたという経験もあったりする😅例えばワークフローの実行時間が長く,完了する前に次のコミットをプッシュしてしまったり,ワークフローの実行が完了する前にプルリクエストをマージしてしまったり💨

concurrency 設定

GitHub Actions ではコンカレンシー (concurrency) という設定があって,ワークフローの同時実行を制御できる.今回はワークフローレベルで試すけど,ジョブレベルで細かく制御することもできる❗️個人的にはとりあえず設定しておいても良さそうかなと思う.

docs.github.com

concurrency サンプル1(待機)

以下の例では GitHub ドキュメントを参考に concurrency.group${{ github.workflow }}-${{ github.ref }}を設定したため concurrency-refs/pull/1/mergeのような名前になり「プルリクエストレベルで」同時実行を制御することになる💡そして concurrency.cancel-in-progressfalseを設定しているため,後続のトリガーはキャンセルにならず実行待機になってから実行される🛑

name: concurrency

on:workflow_dispatch:push:branches:- develop
  pull_request:branches:- develop

concurrency:group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress:falsejobs:sleep:runs-on: ubuntu-latest
    steps:- name: Sleep
        run: sleep 60

concurrency サンプル2(キャンセル)

concurrency.cancel-in-progresstrueを設定すると,実行中のワークフローをキャンセルして最新のワークフローを実行できる🙆‍♂ 例えばデプロイ関連のワークフローであれば最終的に後に実行されたワークフローでデプロイされるため,ワークフローの無駄な実行を回避できて良いと思う👌

name: concurrency

on:workflow_dispatch:push:branches:- develop
  pull_request:branches:- develop

concurrency:group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress:truejobs:sleep:runs-on: ubuntu-latest
    steps:- name: Sleep
        run: sleep 60

CloudFormation の IaC ジェネレーター機能をサクッと試せる「IaC Generator Workshop」

$
0
0

2024年2月にリリースされた AWS CloudFormation の「IaC ジェネレーター機能」を使うとマネジメントコンソール・AWS CLI などを使って作った(作ってしまった)リソースをスキャンして,自動的に AWS CloudFormation テンプレート化 (YAML / JSON) できる❗️もちろんそのまま AWS CloudFormation スタックにリソースをインポートすることもできる.

aws.amazon.com

今までも AWS CloudFormation のインポート機能はあったけど,リソース設定と見比べながら(そしてドリフト機能を活用しながら)テンプレートを書くのはそこそこ大変さがあったと思う.IaC ジェネレーター機能を使う流れは以下のブログにも載っていて,今回紹介するワークショップの内容にも似ている👀

aws.amazon.com

IaC Generator Workshop

この IaC ジェネレーター機能をサクッと試せるワークショップ「IaC Generator Workshop」も公開されていて,試してみた💡

実は2024年2月にワークショップも公開されていて,すぐに試そうと思ったけど,環境セットアップで使うスクリプト infrastructure-script.shにアクセスすると Access Deniedになってしまっていて進めなかった.1ヶ月ほど定期的に確認しても直ってなくて諦めていたけど,最近確認したら修正されていたので,改めてワークショップの内容を確認しておくことにした.

catalog.workshops.aws

ワークショップの内容としては,Amazon VPC 関連リソースと Amazon EC2 インスタンスをスクリプト (AWS CLI) で作って,リソースを AWS CloudFormation の「IaC ジェネレーター機能」でテンプレート化する.以下はスクリプトを実行したときに出力されたリソース情報一覧(既に削除済).

These are the resources created, you will need these ids later in the workshop.
Key Pair:  iacgenerator
VPC ID: vpc-00e0e3957e53ef021
Subnet ID: subnet-05a5cc381ac3dcce6
Internet Gateway ID: igw-0e98de8f97252af56
Route Table ID: rtb-0cff1f90fa8f83671
Security Group ID: sg-0c5db16219d23efd4
Instance ID: i-0c543696db799acf8

そして IaC ジェネレーター機能では,選択したリソースに関連するリソースも自動的に含めることができる.今回のワークショップだと AWS::EC2::NetworkAclAWS::EC2::SubnetNetworkAclAssociationなどは「関連リソース」に含まれていた.

IaC Generator Workshop: テンプレート化

ちなみにテンプレート化したときに「リソース警告」も出ていた.AWS::EC2::InstanceAWS::EC2::Subnetなど IaC ジェネレーター機能でサポートしてるリソースでもプロパティレベルでサポート対象外になっていることもありそうだった.このあたりは影響が出るかどうか確認しつつ,必要ならテンプレートを編集してからインポートすることもできる👌

docs.aws.amazon.com

IaC Generator Workshop: リソース警告

そして,最後はテンプレートをそのまま AWS CloudFormation スタックにインポートする.ちなみに今回のワークショップではテンプレート化するときに DeletionPolicy: Deleteを指定するようになっているため,ワークショップ終了後のお掃除はインポートしたスタックを削除すれば良いという流れになっていた(ちなみに僕の環境だと一部の VPC リソースが削除失敗になってしまった💨).

IaC Generator Workshop: リソースをインポート

まとめ

もしまだ AWS CloudFormation の IaC ジェネレーター機能を試してなくて気になっていれば,1時間以内でサクッと終わるワークショップ「IaC Generator Workshop」がおすすめ❗️

関連ドキュメント

docs.aws.amazon.com

Amazon API Gateway の Lambda オーソライザーで "User is not authorized to access this resource"と出たら

$
0
0

Amazon API Gateway の Lambda オーソライザー(旧カスタムオーソライザー)を使ってアクセス制御をするときに,Authorization ヘッダーは正しいはずなのに {"Message":"User is not authorized to access this resource"}というエラーが出てしまう場合,Lambda オーソライザーの設定「認可のキャッシュ (Authorization caching)」に関係してる場合がある💡

前提

今回はサンプルとして Amazon API Gateway に /usersリソースを追加して POSTGETをサポートする.そしてどちらにも Lambda オーソライザー(トークンタイプ)によるアクセス制御を設定しておく👌

/users (POST)
/users (GET)

そして,Lambda オーソライザーの実装はドキュメントに載っている Python のサンプルコードをそのまま使う📝実装としては簡易的で Authorization ヘッダーに allowと設定すれば OK という仕組みになっている.

docs.aws.amazon.com

ポイントはこの Lambda オーソライザーの実装では以下のようなポリシーが生成されるところ💡(POST の場合)

Allow

{"principalId": "user",
    "policyDocument": {"Version": "2012-10-17",
        "Statement": [{"Action": "execute-api:Invoke",
                "Effect": "Allow",
                "Resource": "arn:aws:execute-api:ap-northeast-1:111111111111:xxxxxxxxxx/Prod/POST/users"
            }]},
    "context": {"stringKey": "stringval",
        "numberKey": 123,
        "booleanKey": true}}

Deny

{"principalId": "user",
    "policyDocument": {"Version": "2012-10-17",
        "Statement": [{"Action": "execute-api:Invoke",
                "Effect": "Deny",
                "Resource": "arn:aws:execute-api:ap-northeast-1:111111111111:xxxxxxxxxx/Prod/POST/users"
            }]},
    "context": {"stringKey": "stringval",
        "numberKey": 123,
        "booleanKey": true}}

動作確認

Amazon API Gateway の /usersリソースに POST リクエストを送信した後すぐに GET リクエストを送信する.すると {"Message":"User is not authorized to access this resource"}というエラーが返ってくる🔥キャッシュの仕組みを理解してないと「なぜー?」となってしまう.キャッシュの TTL はデフォルトで「300秒」に設定されている👀

$ curl -X POST -H'Authorization: allow'${ENDPOINT}/users
$ curl -X GET -H'Authorization: allow'${ENDPOINT}/users
{"Message":"User is not authorized to access this resource"}

対策

選択肢は大きく2つあると思う👌

選択肢1

Lambda オーソライザーで生成するポリシーの条件を緩和する選択肢がある.AWS re:Post の記事にも Resource/*/*にすれば OK という解決策が紹介されている💡もちろんワイルドカードで許可できない場合もあると思うし,最小権限の原則を考慮すると闇雲にワイルドカードっていう判断が危険なこともあると思う.

repost.aws

ちなみに前に紹介記事を書いた Powertools for AWS Lambda (Python)Event Source Data ClassesAPIGatewayAuthorizerResponseを使ってポリシーを生成する場合,allow_all_routes()を使うと以下のようにワイルドカードでポリシーが生成される.allow_route()を使うと HTTP メソッド・リソースを細かく指定できる.

{"principalId": "user",
    "policyDocument": {"Version": "2012-10-17",
        "Statement": [{"Action": "execute-api:Invoke",
                "Effect": "Allow",
                "Resource": "arn:aws:execute-api:ap-northeast-1:111111111111:xxxxxxxxxx/Prod/*/*"
            }]}}

kakakakakku.hatenablog.com

選択肢2

次にキャッシュの TTL を短くする(もしくはキャッシュを無効化する)選択肢がある.キャッシュによる影響はなくなるけど,毎回 Lambda オーソライザーを呼び出すことになるため,パフォーマンスなどの観点で検討が必要になる.

デフォルトで 300 秒、API 所有者が 0~3600 の範囲で設定可能。

docs.aws.amazon.com

PyTorch Tutorials「(optional) Exporting a Model from PyTorch to ONNX and Running it using ONNX Runtime」を試した

$
0
0

PyTorch のチュートリアル「(optional) Exporting a Model from PyTorch to ONNX and Running it using ONNX Runtime」を試した❗️

pytorch.org

PyTorch に低解像度の画像を高解像度の画像に変換する「超解像モデル」のサンプルがあって,今回のチュートリアルではそのモデルを ONNX (Open Neural Network eXchange)にエクスポートして,ONNX Runtime で推論する流れをサクッと体験できる.完全に入門者の僕にピッタリの内容だった👌

github.com

学べたこと

PyTorch のモデルは torch.onnx.export()関数で ONNX にエクスポートできる.

pytorch.org

そして onnxruntime.InferenceSessionクラスの run()関数で推論できる.今回のチュートリアルでは providersCPUExecutionProviderを指定しているけど,CUDA (Compute Unified Device Architecture) 環境があれば CUDAExecutionProviderを指定することもできる.

ort_session = onnxruntime.InferenceSession("super_resolution.onnx", providers=["CPUExecutionProvider"])

onnxruntime.ai

実行結果

PyTorch モデルを ONNX モデルにエクスポートしてから推論した.今回は猫画像🐱を超解像にする内容だった.

実行前

実行後

その他

チュートリアルの範囲外ではあるけど,Netron を使うと ONNX モデルを可視化できる.

netron.app

今回エクスポートした super_resolution.onnxを可視化してみた💡

関連チュートリアル

pytorch.org

AWS Chatbot で AWS Lambda 関数の集約したロググループからログを取得する

$
0
0

AWS Lambda 関数の Errorsメトリクスなどを Amazon CloudWatch Alarm でモニタリングして,エラー発生時に Amazon SNS と AWS Chatbot を組み合わせて Slack に通知すると Show error logsボタンと Show logsボタンが表示される✅ そして AWS Chatbot に権限を与えておくと,Amazon CloudWatch Logs から関連したログを Slack 上で取得できる.エラー発生時に迅速にエラー詳細を把握できるのは便利だと思う👌

Amazon CloudWatch Logs ロググループに注意する

便利な Show error logsボタンと Show logsボタンは AWS Lambda 関数のデフォルトの Amazon CloudWatch Logs ロググループ /aws/lambda/xxxを前提に作られている点は注意しておくと良いと思う.ドキュメントには直接明記されていなかった(見つけられなかった)けど,挙動からそう判断した.

具体的には,2023年11月にリリースされた AWS Lambda 関数の「高度なログ制御機能」を活用して,任意の Amazon CloudWatch Logs ロググループに集約している AWS Lambda 関数でボタンを押すと I can't get the logs for the CloudWatch Alarm sandbox-errors-alarm for you because I cannot find the log group /aws/lambda/sandbox for sandbox.というエラーが出て使えなかった(sandbox-errors-alarmは Amazon CloudWatch Alarm 名 / sandboxは AWS Lambda 関数名).

aws.amazon.com

@awsコマンドを使う

ボタンを押すよりも面倒ではあるけど,ワークアラウンドとして Slack 上で直接 @aws logs filter-log-eventsコマンドを実行すれば,簡易的に AWS Lambda 関数のエラー詳細を把握できる.AWS Chatbot から You can also run the query directly using the following commandとしてコマンド例を出してくれていたため,参考にしながら作ってみた.

ポイントを箇条書きで載せておく📝

  • --log-group-nameに Amazon CloudWatch Logs ロググループを指定する
  • --log-stream-name-prefixに Amazon CloudWatch Logs ログストリームを指定する
  • --start-time--end-timeに Unix Timestamp (Milliseconds) を指定する
@aws logs filter-log-events --region ap-northeast-1 --log-group-name aggregated-function-logs --log-stream-name-prefix2024/04/12/sandbox[$LATEST]--start-time1712883000000--end-time1712883300000

その他のオプションも活用する場合は CLI ドキュメントを参考で👌

awscli.amazonaws.com

そして @awsコマンドを使って AWS Chatbot 経由でログを取得できた.

まとめ

AWS Lambda 関数で任意の Amazon CloudWatch Logs ロググループに集約してる場合は Slack 上で AWS Chatbot の Show error logsボタンと Show logsボタンが使えず,今回は @awsコマンドを使ってワークアラウンドを試してみた.とは言え,正直エラー発生時に @awsコマンドを作るのは面倒ではあるため,本格的に実現するなら「カスタム Lambda アクション (Custom Lambda Action)」を実装する必要がありそう.あと @awsコマンドの引数が多くなければ「カスタム CLI アクション (Custom CLI Action)」を使う案もありそう.

docs.aws.amazon.com

docs.aws.amazon.com

関連記事

kakakakakku.hatenablog.com


データエンジニアリングライフサイクルのステージと底流とは /「データエンジニアリングの基礎」を読んだ

$
0
0

2024年3月に出版された「データエンジニアリングの基礎」を読んだ📕

仕事で取り組んでいることに関係していて,何かしら新しい気付きや発見があれば良いな〜と思って読んでみたけど,期待以上に素晴らしい一冊だった❗️データを取り扱うときに考慮すべきポイントが詳細にまとまっていて,一人で読むのもヨシ!データプロジェクトのメンバーと輪読会をして改善点を洗い出すのもヨシ!という感じで幅広く活用できると思う.

特に本書で重要なのは「データエンジニアリングライフサイクル」というフレームワーク(コンセプト)で,データを活用してプロダクトの価値に変えていくための「ステージ」「底流」から構成されている👌(図を引用できると紹介しやすいんだけど...!)特にデータエンジニアリングライフサイクルのあらゆる側面をサポートする横断的な観点を本書では「底流 (undercurrents)」と表現していて,以下の6種類から構成されていた.本書は全体を通して,データエンジニアリングライフサイクルの観点から解説されていて印象的だった.

  • セキュリティ
  • データ管理
  • DataOps
  • データアーキテクチャ
  • オーケストレーション
  • ソフトウェアエンジニアリング

技術的利害関係者

1章にデータエンジニアに関連する技術的利害関係者の紹介が出てくる.また11章の「職種名と担当範囲は変化する」では担当範囲の境界はますます曖昧になっているとも書いてある.データエンジニアリングライフサイクルを実現するために多くの役割が必要になることは理解できるけど,ある程度の企業規模じゃないとそこまで専任を置くことは難しく,今いるメンバーでどうオーバーラップして前に進めていくかを考えることも重要なのかなと個人的には思った😀また役割のトピックを読んでいて,AWS Well-Architected Machine Learning Lens の「MLOE-04: Establish ML roles and responsibilities」を思い出した.同じく Machine Learning Lens でも役割と責任の分離は明確ではなくオーバーラップすると書いてある.どういう役割が必要なのかを把握することはとても重要❗️

docs.aws.amazon.com

データエンジニアが ML について知っておくべきこと

役割という観点だと,9章で紹介されていた「データエンジニアが ML について知っておくべきこと」というトピックも良かった😃僕自身はアプリケーション・インフラ・DevOps(定義は曖昧だけど)など,ソフトウェア開発に必要なある程度の領域を幅広く得意としているけど,機械学習 (ML) の専門性はなく,ちょうど苦戦しているところだった.

もちろん本書の「まえがき」にデータサイエンティストでは対処できない問題があると書いてある通り,データエンジニアリングライフサイクルを実現するためには特に底流まわりを支援する必要があって,僕自身のスキルセットはフィットしそうだけど,さらに僕自身が機械学習 (ML) の理解を深めることでプロジェクトの価値にさらに貢献できるかなと思っていた.とは言え,どこまで深く理解するべきなのか・そもそも理解できるのかという不安もあり,まずは本書に載っている「知っておくべきこと」の中から理解が浅いところを抑えておきたいなと感じた.

良いデータアーキテクチャの原則

3章に出てくる「良いデータアーキテクチャの原則」は AWS Well-Architected Framework や Google Cloud の 5 Principles for Cloud-Native Architecture にインスパイアされたと書いてあったけど,データエンジニアリングに限らず重要な観点で,紹介されていて良かった👏 逆に普段からソフトウェア開発をしながらこういう原則を意識できていれば,データプロジェクトでも応用しやすいと思う.あと原則7に Jeff Bezos の「Two-Way Door(双方向ドア)」という表現が紹介されていたのもなつかしくて良かった❗️

  • 原則1: 共通コンポーネントを賢く選択する
  • 原則2: 障害に備える
  • 原則3: スケーラビリティ設計
  • 原則4: アーキテクチャはリーダーシップだ
  • 原則5: 常に設計し続ける
  • 原則6: 疎結合システムを構築する
  • 原則7: 可逆な決定をする
  • 原則8: セキュリティを優先する
  • 原則9: FinOps を活用する

aws.amazon.com

読書メモ

他に読書メモに残したことの一部を箇条書きにしておく❗️

  • タイプAデータエンジニアとタイプBデータエンジニア
  • CAO (Chief Analytics Officer): 最高分析責任者
  • CAO-2 (Chief Algorithms Officer): 最高アルゴリズム責任者
  • リバース ETL
  • DMBOK (Data Management Body of Knowledge)
  • The DataOps Manifesto
  • 履歴書駆動開発 (Resume Driven Development)
  • ゼロスケール (Scale to Zero)
  • データカスケード
  • アプリケーションと ML 間での緊密なフィードバック

誤植

  • P13: DMM (Data Management Maturity)のリンクが 404 になっていた
  • P23: 図1-12 の データアーキテクチャデータアーキテクトでは?(原著では Data architectsと書かれていた)

X ポスト🔗

AWS CDK で AWS Step Functions から Amazon SageMaker Processing を .sync で実行する

$
0
0

AWS Step Functions から別のサービスを直接統合するときに「最適化された統合 (Optimized integrations)」「AWS SDK 統合 (AWS SDK integrations)」という選択肢がある.例えば AWS Step Functions から Amazon SageMaker Processingを実行する場合,AWS Step Functions 側で実行完了を待つ必要があることが多く,最適化された統合であれば .syncがサポートされているため,AWS Step Functions の Resourcearn:aws:states:::sagemaker:createProcessingJob.syncと指定すれば簡単に解決できる👏

docs.aws.amazon.com

docs.aws.amazon.com

AWS CDK を使うと

実は AWS CDK では一部の最適化された統合はサポートされてなく,例えば Amazon SageMaker だと CreateHyperParameterTuningJob / CreateLabelingJob / CreateProcessingJobは現状 aws_stepfunctions_tasksに実装されていなかった.

docs.aws.amazon.com

Amazon SageMaker Processing (CreateProcessingJob) に関しては issue も出ていた💡

github.com

よって,現状では AWS CDK の aws_stepfunctions_tasks.CallAwsServiceで AWS SDK 統合を使う必要があるけど,AWS SDK 統合だと別のサービスを呼び出したら終了になってしまうという課題も残る.結果的に .waitForTaskTokenを活用したり,AWS Lambda 関数を独自実装して Amazon SageMaker Processing の DescribeProcessingJob API で ProcessingJobStatusをチェックしたりという工夫が必要になってしまう💨

aws_stepfunctions.CustomStateを使う

少し前置きが長くなったけど,AWS CDK の aws_stepfunctions_tasksでサポートされてなく .syncを実現したい場合に aws_stepfunctions.CustomStateが使える❗️CustomStateを使えば Amazon States Language (ASL)のまま AWS CDK の実装に組み込める.今回は Amazon SageMaker Processing を例に検証したことをまとめておく.基本的に他のアクションでも同じように実現できるはず〜 \( 'ω')/

docs.aws.amazon.com

1. Before: aws_stepfunctions_tasks.CallAwsService

まずは aws_stepfunctions_tasks.CallAwsServiceを使って AWS Step Functions と Amazon SageMaker Processing の「AWS SDK 統合」を実装するサンプルを紹介する.AWS CDK で作るリソースは Amazon SageMaker Processing で動かすコンテナイメージを管理する Amazon ECR 関連と AWS Step Functions 関連で,あとは細かく IAM Role なども必要になってくる.ちなみに Amazon SageMaker Processing ではシンプルに hello-worldイメージを動かすため,ProcessingInputsProcessingOutputConfigなどの設定は省略している😃

docs.aws.amazon.com

ポイントは aws_stepfunctions_tasks.CallAwsServiceservice: 'sagemaker'action: 'createProcessingJob'を設定しているところ.とにかく Amazon SageMaker Processing を実行するだけなら簡単.ちなみに ProcessingJobNameは重複できない仕様になっているため,AWS Step Functions の組み込み関数 States.FormatStates.UUIDを組み合わせて動的に生成するようにした👌組み込み関数便利〜

docs.aws.amazon.com

import{
  Stack,
  StackProps,
  aws_ecr,
  aws_iam,
  aws_stepfunctions,
  aws_stepfunctions_tasks,}from'aws-cdk-lib'import * as ecrdeploy from'cdk-ecr-deployment'import{ Construct }from'constructs'exportclass SandboxCdkSageMakerProcessingStack extends Stack {constructor(scope: Construct, id: string, props?: StackProps){super(scope, id, props)const repository =new aws_ecr.Repository(this,'HelloWorldRepository',{
      repositoryName: 'hello-world',})new ecrdeploy.ECRDeployment(this,'HelloWorldRepositoryDeployment',{
      src: new ecrdeploy.DockerImageName('hello-world'),
      dest: new ecrdeploy.DockerImageName(repository.repositoryUriForTag('latest')),})const sageMakerRole =new aws_iam.Role(this,'SageMakerRole',{
      roleName: 'sandbox-sagemaker-role',
      assumedBy: new aws_iam.ServicePrincipal('sagemaker.amazonaws.com')})

    repository.grantPull(sageMakerRole)const helloWorldProcessingJob =new aws_stepfunctions_tasks.CallAwsService(this,'HelloWorldProcessingJob',{
        service: 'sagemaker',
        action: 'createProcessingJob',
        parameters: {'ProcessingJobName.$': `States.Format('hello-world-{}', States.UUID())`,'RoleArn': sageMakerRole.roleArn,'ProcessingResources': {'ClusterConfig': {'InstanceCount': 1,'InstanceType': 'ml.t3.medium','VolumeSizeInGB': 1,}},'AppSpecification': {'ImageUri': '000000000000.dkr.ecr.ap-northeast-1.amazonaws.com/hello-world'},'StoppingCondition': {'MaxRuntimeInSeconds': 600}},
        iamResources: ['*'],
        additionalIamStatements: [new aws_iam.PolicyStatement({
            actions: ['iam:PassRole'],
            resources: ['*'],})]})new aws_stepfunctions.StateMachine(this,'SandboxStateMachine',{
      stateMachineName: 'sandbox',
      definitionBody: aws_stepfunctions.DefinitionBody.fromChainable(helloWorldProcessingJob),})}}

AWS CDK をデプロイして AWS Step Functions を実行すると,AWS Step Functions はすぐに終了して Amazon SageMaker Processing は裏で動いていた👀

2. After: aws_stepfunctions.CustomState

今度は aws_stepfunctions.CustomStateを使って AWS Step Functions と Amazon SageMaker Processing の「最適化された統合」を実装するサンプルを紹介する.

実装は大きく変化せず,大きく2つのポイントがある.まず1つ目は aws_stepfunctions.CustomStateType: 'Task'Resource: 'arn:aws:states:::sagemaker:createProcessingJob.sync'を設定しているところ.Amazon States Language (ASL)として表現できるため,Amazon SageMaker Processing を .syncで実行できる.ちなみに AWS SDK 統合だと arn:aws:states:::aws-sdk:sagemaker:createProcessingJobという ARN になる💡

2つ目は AWS Step Functions に設定した IAM Role に別途ポリシーを追加する必要があるところ.aws_stepfunctions_tasks.CallAwsServiceだと iamResources / iamAction / additionalIamStatementsあたりを設定すれば自動的にポリシーが追加される仕組みになっている.ちなみに今回の例はポリシーを少し雑に設定しているため,最小権限の原則に沿って狭めてもらえると良いかと🙏

import{
  Stack,
  StackProps,
  aws_ecr,
  aws_iam,
  aws_stepfunctions,}from'aws-cdk-lib'import * as ecrdeploy from'cdk-ecr-deployment'import{ Construct }from'constructs'exportclass SandboxCdkSageMakerProcessingStack extends Stack {constructor(scope: Construct, id: string, props?: StackProps){super(scope, id, props)const repository =new aws_ecr.Repository(this,'HelloWorldRepository',{
      repositoryName: 'hello-world',})new ecrdeploy.ECRDeployment(this,'HelloWorldRepositoryDeployment',{
      src: new ecrdeploy.DockerImageName('hello-world'),
      dest: new ecrdeploy.DockerImageName(repository.repositoryUriForTag('latest')),})const sageMakerRole =new aws_iam.Role(this,'SageMakerRole',{
      roleName: 'sandbox-sagemaker-role',
      assumedBy: new aws_iam.ServicePrincipal('sagemaker.amazonaws.com')})

    repository.grantPull(sageMakerRole)const helloWorldProcessingJob =new aws_stepfunctions.CustomState(this,'HelloWorldProcessingJobCustom',{
        stateJson: {
          Type: 'Task',
          Resource: 'arn:aws:states:::sagemaker:createProcessingJob.sync',
          Parameters: {'ProcessingJobName.$': `States.Format('hello-world-{}', States.UUID())`,'RoleArn': sageMakerRole.roleArn,'ProcessingResources': {'ClusterConfig': {'InstanceCount': 1,'InstanceType': 'ml.t3.medium','VolumeSizeInGB': 1,}},'AppSpecification': {'ImageUri': '000000000000.dkr.ecr.ap-northeast-1.amazonaws.com/hello-world'},'StoppingCondition': {'MaxRuntimeInSeconds': 600}},}})new aws_stepfunctions.StateMachine(this,'SandboxStateMachine',{
      stateMachineName: 'sandbox',
      definitionBody: aws_stepfunctions.DefinitionBody.fromChainable(helloWorldProcessingJob),}).addToRolePolicy(new aws_iam.PolicyStatement({
          actions: ['events:DescribeRule','events:PutRule','events:PutTargets','iam:PassRole','sagemaker:AddTags','sagemaker:CreateProcessingJob',],
          resources: ['*'],}))}}

AWS CDK をデプロイして AWS Step Functions を実行すると,今度は Amazon SageMaker Processing の実行完了まで待てるようになった❗️やったー👏

Amazon SageMaker Processing Job を2回実行したログも載せておく📝

SageMaker の地理空間機能を試そう: How to use SageMaker Processing with geospatial image

$
0
0

Amazon SageMaker が「地理空間 (Geospatial)」に特化した機能を限定的に(us-west-2 のみ)提供していることを最近知った🌍

aws.amazon.com

そして Amazon SageMaker Examples を確認したら地理空間機能を試せるサンプルがあったため,「How to use SageMaker Processing with geospatial image」を試してみた❗️

github.com

How to use SageMaker Processing with geospatial image の概要としては Amazon SageMaker Processing を使って SENTINEL-2 の衛星画像データから NDVI (Normalized Difference Vegetation Index)を計算する.NDVI は植物の反射の特性から簡易的に植生の状況を把握するために使う指標で,詳細は国土地理院のサイトなどに載っている🌿

www.gsi.go.jp

drone.kmtech.jp

実施前の注意点としては Amazon SageMaker の地理空間機能自体に課金体系があって「月額 150 USD」支払う必要があるところ.無料利用枠もあるけど,地理空間機能自体の利用履歴ではなく「Amazon SageMaker リソースを作成してから60日間」となり,過去に Amazon SageMaker の代表的な機能を使っていると即課金になってしまう.今回の Jupyter Notebook は Amazon SageMaker Studio Classic の ml.geospatial.interactiveインスタンス上で動かすため,課金体系を調べてから慎重に使うと良いかなと💰

aws.amazon.com

学べたこと

boto3 に実装されてる SageMakergeospatialcapabilitiesは知らなかった💡今回は search_raster_data_collection関数を使って SENTINEL-2から北アメリカアイダホ州の衛星画像データを取得した.検索フィルタの AreaOfInterestGeometryに GeoJSON を設定するなど,位置情報に慣れていれば問題なく使えそう🌍

boto3.amazonaws.com

Amazon SageMaker Processing の ScriptProcessor で地理空間処理を実行する場合はコンテナイメージとして 081189585635.dkr.ecr.us-west-2.amazonaws.com/sagemaker-geospatial-v1-0:latestを指定する.現時点だと us-west-2(オレゴン)限定だしイメージ URL は固定のようだった.また準備として実行ロールに AmazonSageMakerGeospatialFullAccessマネージドポリシーをアタッチしておく必要もある👌

docs.aws.amazon.com

最終的に Amazon SageMaker Processing で計算した NDVI を Matplotlib で可視化する.場所的にはローウェル湖 (Lake Lowell)周辺で,サンプルとして選ばれた 2022/03, 2022/06, 2022/07, 2022/08, 2022/09 を比較すると時期による NDVI の変化(3月は NDVI 低め)を確認できたりする👀

Example: NDVI for 03/2022

Example: NDVI for 06/2022

Example: NDVI for 07/2022

Example: NDVI for 08/2022

Example: NDVI for 09/2022

その他

Jupyter Notebook の CI Badge が古くてエラーになっていたのは直してプルリクエストを送っておいた✅

github.com

まとめ

月額課金もあって気軽に試しにくくはあるけど,他にもまだまだ地理空間機能があって興味はあるので勉強していこう❗️

docs.aws.amazon.com

関連記事

位置情報などを基礎から学ぶなら「現場のプロがわかりやすく教える位置情報エンジニア養成講座」がおすすめで過去に書評記事を書いた📕

kakakakakku.hatenablog.com

認定資格 HashiCorp Certified: Terraform Associate の対策にも使える「Terraform の教科書」を読んだ

$
0
0

2024年3月21日に出版された「Terraform の教科書」を読んだ📕

本書は「これから Terraform に入門したいと思っている初学者」に特におすすめできる一冊だった.また本書では原著と違って,2024年1月にリリースされた Terraform v1.7.0 をベースに修正されていて,情報の鮮度が意識されているのも素晴らしかった👌

目次

  • Part 1: 基礎知識
    • 1章: IaC を知る
    • 2章: Terraform のインストール
  • Part 2: コア・コンセプト
    • 3章: Terraform をはじめよう
    • 4章: Terraform へのディープダイブ
    • 5章: Terraform CLI
    • 6章: Terraform のワークフロー
    • 7章: Terraform のモジュール
  • Part 3: Terraform によるインフラストラクチャの管理
    • 8章: Terraform の構成ファイル
    • 9章: Terraform スタックを理解する
    • 10章: Terraform Cloud と Terraform Enterprise
  • 付録A: Terraform 用語集
  • 付録B: 解答と解説

PDF で読むなら「マイナビブックス」で購入できる👌

book.mynavi.jp

AWS / Google Cloud / Azure サポート

本書を読んでまず驚いたのは,Terraform を学ぶ題材として,AWS (Amazon Web Services), Google Cloud, Microsoft Azure 3種類のプロバイダーの解説をサポートしているところで,多くのトピックで3種類のサンプルコードが紹介されていた👀

これから Terraform に入門する初学者のことを考えると,もちろん仕事で使うパブリッククラウドを題材として Terraform を学べるのが1番効率が良く,例えば仕事では AWS を使っているけど,書籍では Google Cloud で紹介されていると,内容的には一般的なトピックだとしても,イメージが湧きにくかったり,読みながら挫折してしまうことにも繋がると思う.3種類のプロバイダーをサポートしているのは本書の特徴の一つだと思う❗

逆に言えば3種類の解説にページを割く必要があって,計400ページというのは本書の目次と解説のレベル感から考えると多少多いようには感じた.

認定資格サポート

本書のもう一つの特徴として,HashiCorp 公式の認定試験「HashiCorp Certified: Terraform Associate」に対応しているという点がある.今まで認定資格の対策として使えると謳った Terraform 関連書籍はなかったと思う(たぶん).

ちなみに本書の表紙には「Terraform Associate exam 対応」と書かれていて,冒頭の「本書について」では 本書は Terraform アソシエイト試験を受験しようとしている人のために作られたと書いてある📝 そして,本書の各章末には Questions という練習問題が収録されていて,認定資格対策として使える❗

実際に僕は2023年7月に HashiCorp Certified: Terraform Associate (003)を取得しているけど,出題範囲に近く構成されているとは思った.とは言え,Terraform CLI の詳細・シークレット管理など不足してるトピックもある印象なので認定資格を受験するときは他にも対策は必要だと思う💡

kakakakakku.hatenablog.com

Terraform Cloud と Terraform Enterprise

10章に Terraform Cloud(ちなみに2024年4月22日から HCP Terraform に改名された)と Terraform Enterprise の解説が入っているのは良かった👌また画面キャプチャも多くてイメージを掴みやすいと思う.もちろん認定試験の出題範囲に Terraform Cloud が入っているからという背景もあるとは思うけど,実際に Terraform Cloud や Terraform Enterprise を使って Terraform のワークフローを運用してるチームも多いと思うし(実際に僕も仕事では Terraform Cloud を使っている),使うとどういうメリットがあるのかを把握しておくことは重要だと思う.

また2023年5月に変更された料金プランが反映された機能比較表も載っていて素晴らしかった👏

www.hashicorp.com

誤植

読みながら気付いたところをまとめておく📝(サポートサイトに未掲載のもののみ)

  • P.21: 古いレゴシステム古いレガシーシステム(レゴシステムという言葉に馴染みがなく気になったけど実は一般的な用語?)
  • P.119: ステートファイル保存するステートファイルを保存する
  • P.125: チームメンバーににチームメンバーに
  • P.289: GithubGitHub
  • P.316: 書かれています、書かれています。

book.mynavi.jp

あと誤植ではないけど少し気になったのは,一部のサンプルコードでリソース名にハイフンが使われていたところ.Terraform Style Guide / Google Cloud Terraform Best practices など,基本的にはリソース名の単語区切りにはアンダースコアが推奨されているため,今後 Terraform に入門する人は以下のドキュメントなどもあわせて読んでおくと良いと思う😀

developer.hashicorp.com

cloud.google.com

詳解 Terraform 第3版

あくまで個人的な感想として,2023年11月に出版された「詳解 Terraform 第3版」との比較をまとめておく.優劣を付けたいという意味ではなく読者層の違いがあると感じた❗

まず,認定資格 HashiCorp Certified: Terraform Associateの取得を目指していたり,基礎の基礎から Terraform を学びたいという初学者には「Terraform の教科書」が良いと思う.また AWS / Google Cloud / Azure をサポートしているため,特に Google Cloud / Azure のサンプルを参考に学びたかったら「Terraform の教科書」が良いと思う💡

Terraform に関して学べる技術的なレベルの深さという観点だと「詳解 Terraform 第3版」はより実践的なので,もちろん初学者も読めるけど,中級者におすすめできると思う.また多くのサンプルコードが AWS プロバイダーを前提にしているため,仕事で AWS を使っている場合にもおすすめ.よって,「Terraform の教科書」の目次をザッと見て,ある程度わかるな〜と感じるのであれば,最初から「詳解 Terraform 第3版」を読むのが良いかなと思う👌

CodeBuild の GitHub Actions ランナーサポートを Lambda 実行環境で試した

$
0
0

2024年4月24日に AWS CodeBuild で GitHub Actions ランナーがサポートされた❗️そして,2023年11月には AWS CodeBuild の実行環境として AWS Lambda を選択できるようになっているため,今回は個人的な検証として GitHub Actions x AWS CodeBuild (AWS Lambda) の組み合わせを試してみた \( 'ω')/

aws.amazon.com

aws.amazon.com

セットアップ

以下のドキュメントを参考に AWS CodeBuild プロジェクトをセットアップする.ポイントとしては Wehbook の Filter Group に WORKFLOW_JOB_QUEUEDを選択するところ💡ちなみに WORKFLOW_JOB_QUEUEDを選択する場合は Buildspecは設定できず,コンソールだと Buildspec will be ignored when you use CodeBuild to run GitHub Actions workflow jobs. Instead, CodeBuild will override it to use commands that will setup the self-hosted runner.という警告が出ていた💨

docs.aws.amazon.com

あと実行環境として AWS Lambda を選択する場合はランタイムも選択する必要があるため,今回は Python 3.12 (aws/codebuild/amazonlinux-x86_64-lambda-standard:python3.12)にした.

docs.aws.amazon.com

ちなみに AWS CDK で AWS CodeBuild プロジェクトをセットアップしようと思ったけど,現時点では aws_codebuild.EventActionWORKFLOW_JOB_QUEUEDを設定できなかった.L1 Construct の CfnProjectなら設定できそう.今回はコンソールを使って設定することにした.

docs.aws.amazon.com

GitHub Actions ワークフロー

今回は以下のように実装してみた😀

ポイントは runs-onで,普段は ubuntu-latestを設定したりするけど,ここに決まったフォーマットを指定することで AWS CodeBuild プロジェクトと紐付けられる.ドキュメントに載っていた runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}というフォーマットをそのまま使った.今回検証で使う AWS CodeBuild プロジェクト名は sandboxにしてある.

name: GitHub Actions runners in CodeBuild

on:workflow_dispatch:push:branches:- master
  pull_request:branches:- master

jobs:build:runs-on: codebuild-sandbox-${{ github.run_id }}-${{ github.run_attempt }}
    steps:- uses: actions/checkout@v4
      - run: python src/app.py
      - run: env | grep LAMBDA

そして GitHub Actions ワークフローのステップでは,以下の Python コード src/app.pyを実行しつつ,AWS Lambda に関係する環境変数を取得するスクリプトを設定してみた💡

import platform

print(platform.python_version())

実行結果

GitHub Actions を実行すると,すぐに AWS CodeBuild でビルドが実行されていた❗️AWS CodeBuild 側のログには GHA self-hosted runnerと表示されていた.

Configuring GHA self-hosted runner


--------------------------------------------------------------------------------
|        ____ _ _   _   _       _          _        _   _                      |
|       / ___(_) |_| | | |_   _| |__      / \   ___| |_(_) ___  _ __  ___      |
|      | |  _| | __| |_| | | | | '_ \    / _ \ / __| __| |/ _ \| '_ \/ __|     |
|      | |_| | | |_|  _  | |_| | |_) |  / ___ \ (__| |_| | (_) | | | \__ \     |
|       \____|_|\__|_| |_|\__,_|_.__/  /_/   \_\___|\__|_|\___/|_| |_|___/     |
|                                                                              |
|                       Self-hosted runner registration                        |
|                                                                              |
--------------------------------------------------------------------------------

そして GitHub Actions 側のログは以下のようになっていた.Python バージョンは 3.12.0だったり,AWS_LAMBDA_FUNCTION_NAMEという環境変数から customer-xxxという名前の AWS Lambda 関数が実行されていることなどを確認できた👏(検証用の AWS CodeBuild プロジェクトは既に削除しつつ,関数名はマスキングしてある)

▶Run python src/app.py
3.12.0

▶Run env | grep LAMBDA
AWS_LAMBDA_FUNCTION_VERSION=$LATEST
LAMBDA_USER_HOME=/tmp/opt
LAMBDA_TASK_ROOT=/var/task
AWS_LAMBDA_RUNTIME_API=127.0.0.1:9001
AWS_LAMBDA_FUNCTION_MEMORY_SIZE=1024
LAMBDA_RUNTIME_DIR=/var/runtime
AWS_LAMBDA_FUNCTION_NAME=customer-000000000000-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxx
AWS_LAMBDA_INITIALIZATION_TYPE=on-demand

できなかったこと

AWS CodeBuild プロジェクトの実行環境を Amazon EC2 ベースにする場合は,runs-oncodebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}-<image>-<image-version>-<instance-size>というフォーマットに沿って指定すると環境設定を上書きできるという柔軟さがある.

しかし実行環境を AWS Lambda ベースにする場合だとランタイム・メモリサイズなどを上書きすることはできなさそうだった.ドキュメントにも特に記載はなかった💨 現状ではまだ柔軟な利用はできなさそう.

まとめ

リリースされて気になっていた AWS CodeBuild の GitHub Actions ランナーサポートと AWS Lambda の組み合わせを個人的な検証として試してみた❗️あくまでリリース直後に試してみたレベルの感想ではあるけど,セットアップは比較的簡単で,頻繁に実行する短めのジョブ(例えば Linter 実行・軽めのスキャン実行など)に使うのは相性が良さそうだった.

しかし AWS CodeBuild と AWS Lambda を組み合わせるときの制約もドキュメントに書かれていて,例えば Docker ビルド・VPC 接続はできず,もちろん実行時間の上限もある.そして,今回試した実行環境の設定を上書きすることも現状ではできなさそうだった.制約をうまく活用できるかがポイントになりそう.

docs.aws.amazon.com

あとは Webhook のイベントタイプ WORKFLOW_JOB_QUEUEDを現状 AWS CDK / Terraform で設定できないところも気になるけど,AWS CloudFormation では既にサポートされてそうだし,少し待っていれば解決しそうではある.

docs.aws.amazon.com

ちなみに個人的に GitHub Actions と AWS CodeBuild を組み合わせるときは AWS CodeBuild Run Build for GitHub Actions (aws-actions/aws-codebuild-run-build) を使うことが多く,パラメータの上書きなども柔軟にできて,モノリポ運用との相性もよくて気に入っている👌 参考まで〜

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Amazon Rekognition / Amazon Lookout for Vision などを試しながら学べる「AWS コンピュータービジョン開発の教科書」を読んだ

$
0
0

2024年3月19日に出版された「AWS コンピュータービジョン開発の教科書」を読んだ📕

コンピュータビジョンは今取り組んでいる仕事にも関連していて,本書の目次を見たら今まで試したことがなかったようなサービスも学べそうだったので,実は出版前から興味を持っていた💡今回は本書を読むだけではなく,気になったトピックを実際に試しながら進めた.

本書では AWS サービスを活用してコンピュータビジョンシステム(用語の定義は以下の what-isサイトを参照)を構築する方法を学べる🤖 とは言え AWS サービスもいくつかあって,まずは本書の目次を見てみるのが1番良いと思う.具体的なサービスと機能だと Amazon Rekognition / Amazon Rekognition Custom Labels / Amazon Lookout for Vision / Amazon SageMaker / Amazon SageMaker Ground Truth / AWS IoT Greengrass などを中心に学べる.これらのサービスをあまり試したことがなかったり,目次を見て興味を持ったら本書の読者層だと思う❗️

aws.amazon.com

目次

  • Part 1: AWS と Amazon Rekognition でのコンピュータービジョンの紹介
    • 1章: コンピュータービジョン・アプリケーションと AWS の AI・機械学習サービスの概要
    • 2章: Amazon Rekognition の利用
    • 3章: Amazon Rekognition Custom Labels を使用したカスタムモデルの作成
  • Part 2: 実世界のユースケースへのコンピュータービジョンの適用
    • 4章: 本人確認を使用した非接触型ホテルチェックインシステムの構築
    • 5章: 動画解析パイプラインの自動化
    • 6章: AWS AI サービスによるコンテンツの検閲
  • Part 3: エッジでのコンピュータービジョン
    • 7章: Amazon Lookout for Vision の紹介
    • 8章: エッジでのコンピュータービジョンを使用した製造不良の検出
  • Part 4: Amazon SageMaker を使用したコンピュータービジョン・ソリューションの構築
    • 9章: Amazon SageMaker Ground Truth を使用したデータのラベル付け
    • 10章: コンピュータービジョンでの Amazon SageMaker の使用
  • Part 5: コンピュータービジョン・アプリケーションの運用環境ワークロードのベストプラクティス
    • 11章: Amazon Augmented AI (A2I) によるヒューマン・イン・ザ・ループの統合
    • 12章: エンドツーエンドのコンピュータービジョン・パイプライン設計のベストプラクティス
    • 13章: コンピュータービジョンへの AI ガバナンスの適用

PDF で読むなら「マイナビブックス」で購入できる👌

book.mynavi.jp

Amazon Rekognition Custom Labels

3章では Amazon Rekognition Custom Labelsを使ってデータセットに対して出版社ロゴの Packtにバウンディングボックスを付けて,トレーニングしたモデルをデプロイする流れを体験できる.Amazon Rekognition Custom Labels 自体は過去に使ったことがあるけど,改めてやってみた❗️今回はデータセットが10枚だから簡単だけど多いと大変な作業だな〜と思ったりもした(ワークフォースに関しては9章につながる).

Amazon Rekognition Custom Labels

Amazon Rekognition を活用したチェックインシステム

4章に出てくるチェックインシステムでは,Amazon Rekognition のコレクションDetectFaces APIや Amazon Textract の AnalyzeID APIなどの機能を組み合わせてソリューションが実現されていて参考になった.最終的には aws-samples に公開されている Amazon Rekognition Identity Verification (RIV)ソリューションにつながっていて,本書を読まなくても試せるようになっていた.

github.com

ちなみに4章を読んでるときに Auto Check-In Appソリューションにも少し似てるな〜なんて思ったりもしていた💡

aws.amazon.com

Amazon Lookout for Vision

7章では Amazon Lookout for Visionを使って錠剤に欠陥があるかを検査する仕組みを構築した💊 実は今まで Amazon Lookout for Vision を使ったことがなくて,流れを体験できたのはとても良かった👌流れとしては GitHub に公開されているデータセットを使ってモデルをトレーニングして,トライアル検出タスクを使ってモデルを評価した.そして最後はデプロイしたモデルに対して別の画像を検査して,結果的に 93.74% の信頼度を得ることができた \( 'ω')/

$ aws lookoutvision detect-anomalies \--project-name pills-damage-detection \--model-version1\--content-type image/png \--body 07_LookoutForVision/images/anomaly/pic.6.615.0.png \--region us-east-2
{"DetectAnomalyResult": {"Source": {"Type": "direct"},
        "IsAnomalous": true,
        "Confidence": 0.9374997019767761}}

Amazon Lookout for Vision: トライアル検出タスク

読書メモ

他に読書メモに残したことの一部を箇条書きにしておく❗️

本書のサンプルコード・データセットは以下で確認できる.

github.com

誤植

読みながら気付いたところをまとめておく📝(サポートサイトに未掲載のもののみ)

  • P.23: m1.t3.mediumml.t3.medium
  • P.40: recognition =rekognition =
  • P.41: GraphzivGraphviz
  • P.89: 実際に実行すると CreationTimestampのフォーマットが異なる!?
  • P.165: for record in event['Records']:の改行漏れ
  • P.193: 図7.14 で trailtrial
  • P.210: 説明は EC2 Instance Connectだけど図8.9 は AWS Systems Manager Session Managerになっている
  • P.228: インポートする築インポートする

book.mynavi.jp

関連情報

Amazon SageMaker の機能や MLOps などワークフローまわりを深く学ぶのであれば「実践 AWS データサイエンス」に詳しく書かれていておすすめ❗️僕は2022年にこの本を読んで(書評記事は書いていないけど...)Amazon SageMaker の理解度がグッと高まったな〜と感じた.

また画像分類という領域だと,最近 AWS Prescriptive Guidance に「Image classification solutions on AWS」というドキュメントが追加されていたりする.技術的な選択肢やベストプラクティスは AWS Prescriptive GuidanceAWS Well-Architected Framework Machine Learning Lensなどをあわせて読むと良さそう👌

docs.aws.amazon.com

docs.aws.amazon.com

「Terraform の教科書 - Forkwell Library #51」で Q&A セッションのモデレーターを担当した

$
0
0

2024年5月9日に開催されたオンラインイベント「Terraform の教科書 - Forkwell Library #51」で Q&A セッションのモデレーター(司会者)を担当させて頂いたので,イベント開催前の準備などを簡単にまとめておこうと思う \( 'ω')/

今回は貴重な機会を頂きましてありがとうございました❗️そしてお疲れさまでした〜

forkwell.connpass.com

イベント準備 🎤

2024年4月24日(イベントの2週間前頃)にモデレーターのお話を頂き,正直僕で良いのかな〜と少し悩んだけど,せっかくの機会なので担当させて頂くことにした❗️イベント内容を確認したところ,2024年3月21日に出版された「Terraform の教科書」を翻訳されたねこやまさん @noriko_roが基調講演をされるとのことで,すぐに「Terraform の教科書」を読み始めて,本書の特徴・読者層などを整理しつつ,書評記事も書いたりした📝

kakakakakku.hatenablog.com

そして,本書はどちらかと言うと Terraform 初学者をターゲットにした一冊だったため,これから Terraform に入門する初学者の気持ちになって「どういうところに疑問を持つか」を考えながら「想定質問集」を作ったりしていた.そもそも僕自身も Terraform を本格的に使い始めたのは2023年5月(ちょうど1年前📅)で,1年前に僕自身がどういう疑問を持っていたかを思い出すのも役に立った.また友人にも Terraform を学び始めるときに悩んだことなどをヒアリングして,客観的な視点も意識した👀

イベント当日 🎤

イベント当日のアーカイブ動画は YouTube に公開されてるので観てもらえればと❗️ねこやまさんの基調講演はとてもわかりやすくて良かった〜👏

そして,Q&A セッションでピックアップした質問(シンプルに書き直している)はザッと以下のような感じ💡ちなみに本書の読者層に沿って初学者の質問を多く拾おうと思っていたけど,実際に投稿して頂いた質問の多くが実践的な質問で少し焦ったけど,アドリブと瞬発力でねこやまさんと一緒に答えられたかな〜と思う.

  • Terraform Cloud (HCP Terraform) を使うメリットは何?
  • AWS Provider と Google Cloud Provider の共通点・差異はある?
  • ディレクトリ構成のおすすめ・tfstate 分割単位のおすすめはある?
  • Terraform Modules は使うべき?使わないべき?
  • Terraform 管理外のリソースが多くあるプロジェクトを Terraform 化する戦略はある?
  • 逆に IaC (Infrastructure as Code) をせずコンソール管理をするべきリソースはある?
  • 例外的にコンソールでリソースを変更する場面はある?
  • Terraform と他の IaC ソリューションを比較して Terraform が苦手なことはある?
  • HashiCorp Certified: Terraform Associate に合格するコツはある?
  • AWS のリソース管理に AWS CloudFormation ではなく Terraform を使うメリットはある?
  • Terraform の開発に役立つおすすめツールはある?
  • Terraform・Provider のバージョンアップ戦略はどうすれば?
  • etc

他にも多く質問があったけど時間の関係で拾えなくてゴメンナサイ🙏 多くの質問・X ポストありがとうございました〜 \( 'ω')/

www.youtube.com

関連記事

kakakakakku.hatenablog.com


Python でツリー構造を表現できる treelib

$
0
0

Python ライブラリ treelibを使うと簡単にツリー構造を表現できる.今まで使ったことがなくて,ドキュメントを見ながら基本的な操作を試してみた🌴

treelib.readthedocs.io

github.com

ちなみに treelib は「AWS コンピュータービジョン開発の教科書」を読んでいたら,Amazon Rekognition のラベル検出結果をツリー構造で表示するために使われていて,本のトピックと直接は関係ないけど「こんなのあるんだ〜💡」と気になってしまった \( 'ω')/

kakakakakku.hatenablog.com

サンプル

今回はサンプルとして以下のようなツリー構造を treelib で作って,気になった操作を試してみる❗️サポートされてる全ての操作はドキュメント参照📝

root
├── A01
│   └── A11
├── B01
│   ├── B11
│   └── B12
│       ├── B121
│       └── B122
└── C01
    ├── C11
    ├── C12
    └── C13

ツリー構造を作る

以下のように Tree()create_node()でツリー構造を簡単に表現できる.子ノードを作るときは create_node()parentを指定すれば OK👌

from treelib import Tree

tree = Tree()

root = tree.create_node('root')
a01 = tree.create_node('A01', parent=root)
a11 = tree.create_node('A11', parent=a01)
b01 = tree.create_node('B01', parent=root)
b11 = tree.create_node('B11', parent=b01)
b12 = tree.create_node('B12', parent=b01)
b121= tree.create_node('B121', parent=b12)
b122= tree.create_node('B122', parent=b12)
c01 = tree.create_node('C01', parent=root)
c11 = tree.create_node('C11', parent=c01)
c12 = tree.create_node('C12', parent=c01)
c13 = tree.create_node('C13', parent=c01)

表示する

show()を使えばツリー構造をそのまま表示できる.

# root# ├── A01# │   └── A11# ├── B01# │   ├── B11# │   └── B12# │       ├── B121# │       └── B122# └── C01#     ├── C11#     ├── C12#     └── C13print(tree.show(stdout=False))

JSON に変換する

to_json()を使えばツリー構造を JSON に変換して表示できる.

# {"root": {"children": [{"A01": {"children": ["A11"]}}, {"B01": {"children": ["B11", {"B12": {"children": ["B121", "B122"]}}]}}, {"C01": {"children": ["C11", "C12", "C13"]}}]}}print(tree.to_json())

JSON をフォーマットすると以下のようになる💡

{"root": {"children": [{"A01": {"children": ["A11"
                    ]}},
            {"B01": {"children": ["B11",
                        {"B12": {"children": ["B121",
                                    "B122"
                                ]}}]}},
            {"C01": {"children": ["C11",
                        "C12",
                        "C13"
                    ]}}]}}

Graphviz に変換する

to_graphviz()を使えば .dotファイルに変換できる.

tree.to_graphviz('tree.dot')

ファイルに出力する

save2file()を使えばツリー構造をそのままファイルに出力できる.

tree.save2file('tree.txt')

深さを確認する

depth()を使えばツリー構造の深さを確認できる.

# 3print(tree.depth())

子ノードを取得する

children()を使えば子ノードのリストを取得できる.

# node.tag='B121' node.identifier='cc4caccc-023e-11ef-bdee-5a033878925f'# node.tag='B122' node.identifier='cc4cacfe-023e-11ef-bdee-5a033878925f'
b12_children = tree.children(b12.identifier)
for node in b12_children:
    print(f'{node.tag=} {node.identifier=}')

部分木を取得する

subtree()を使えば部分木を取得できる.

# B01# ├── B11# └── B12#     ├── B121#     └── B122
subtree_b01 = tree.subtree(b01.identifier)
print(subtree_b01.show(stdout=False))

ノードを削除する

remove_node()を使えばツリー構造からノードを削除できる.

# root# ├── A01# │   └── A11# └── B01#     ├── B11#     └── B12#         ├── B121#         └── B122
tree.remove_node(c01.identifier)
print(tree.show(stdout=False))

関連記事

tree.nathanfriend.ioを使うと「tree コマンド風の」ディレクトリ構造をウェブサイトで簡単に生成できて便利❗️

kakakakakku.hatenablog.com

AWS Step Functions の TestState API でステートをテストしよう!

$
0
0

AWS Step Functions ワークフローを実装しているときに,ステートをデプロイする前にテストしたり,デプロイしたワークフローの特定のステートのみを実行したいという場面があったりする.実は AWS Step Functions の「TestState API」を使うと,ワークフローをデプロイせずに1つのステートをテストできてスムーズに実装を進められる👌

ちなみに TestState API は2023年11月末にリリースされている❗️

aws.amazon.com

docs.aws.amazon.com

AWS CLI で TestState API を試す

AWS CLI の aws stepfunctions test-stateコマンドを使えば TestState API を簡単に試せる.aws stepfunctions test-stateコマンドの必須オプションは大きく2つ(--definition--role-arn)ある.--definitionを指定するため,実際に AWS Step Functions ワークフローをデプロイする必要はなく,Amazon States Language (ASL) を直接指定してテストできる👌

awscli.amazonaws.com

1. Lambda Invoke を試す 🧩

実際に存在する AWS Lambda 関数を呼び出すステートを JSON で定義する📝

{"Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "OutputPath": "$.Payload",
    "Parameters": {"Payload.$": "$",
        "FunctionName": "arn:aws:lambda:ap-northeast-1:000000000000:function:xxxxxxx:$LATEST"
    },
    "End": true}

ステートのイメージは以下のような感じ.

そしてコマンドを実行すると指定したワークフロー定義から AWS Lambda 関数を呼び出せた👏

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{ "key1": "value1", "key2": "value2" }'{"output": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}",
    "status": "SUCCEEDED"}

2. S3 PutObject を試す 🧩

次に AWS Step Functions の「SDK 統合」を使って,実際に存在する Amazon S3 バケットにオブジェクトを保存するステートを JSON で定義する📝

{"Type": "Task",
    "Resource": "arn:aws:states:::aws-sdk:s3:putObject",
    "Parameters": {"Body.$": "$.body",
        "Bucket": "xxxxxxxxxx",
        "Key": "aws-stepfunctions-test-state.txt"
    },
    "End": true}

ステートのイメージは以下のような感じ.

そしてコマンドを実行すると指定したワークフロー定義から Amazon S3 バケットにオブジェクトを保存できた👏

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{ "body": "hello!" }'{"output": "{\"ETag\":\"\\\"1092c22d20edf737ded7bfb149dd8c9e\\\"\",\"ServerSideEncryption\":\"AES256\"}",
    "status": "SUCCEEDED"}

3. Choice (NumericEquals) を試す 🧩

今度は AWS Step Functions の Choiceドキュメントに載っている NumericEqualsのサンプルを参考に分岐のあるステートを JSON で定義する📝

{"Type": "Choice",
    "Choices": [{"Variable": "$.foo",
            "NumericEquals": 1,
            "Next": "FirstMatchState"
        }],
    "Default": "Success"
}

ステートのイメージは以下のような感じ.

分岐をテストするために { "foo": 1 }{ "foo": 100 }を指定してコマンドを実行すると,期待した nextStateになっていることを確認できた👏

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{ "foo": 1 }'{"output": "{ \"foo\": 1 }",
    "nextState": "FirstMatchState",
    "status": "SUCCEEDED"}

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{ "foo": 100 }'{"output": "{ \"foo\": 100 }",
    "nextState": "Success",
    "status": "SUCCEEDED"}

4. Choice (IsNull) を試す 🧩

もう一つ AWS Step Functions の Choiceドキュメントに載っている IsNullのサンプルを参考に分岐のあるステートを JSON で定義する📝

{"Type": "Choice",
    "Choices": [{"Variable": "$.possiblyNullValue",
            "IsNull": true,
            "Next": "Fail"
        }],
    "Default": "Success"
}

ステートのイメージは以下のような感じ.

分岐をテストするために { "possiblyNullValue": 12345 }{}を指定してコマンドを実行すると,期待した nextStateになっていることを確認できた👏

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{ "possiblyNullValue": 12345 }'{"output": "{ \"possiblyNullValue\": 12345 }",
    "nextState": "Success",
    "status": "SUCCEEDED"}

$ aws stepfunctions test-state \--definition file://state.json \--role-arn arn:aws:iam::000000000000:role/xxxxx \--input'{}'{"error": "States.Runtime",
    "cause": "Invalid path '$.possiblyNullValue': The choice state's condition path references an invalid value.",
    "status": "FAILED"}

マネジメントコンソールで TestState API を試す

TestState APIは AWS Step Functions のマネジメントコンソールでも使える❗️

デプロイ前のワークフローであれば AWS Step Functions Workflow Studio で テスト状態というボタンを押す.さらにデプロイして実行した AWS Step Functions ワークフローに対しても,特定のステートを選択して テスト状態というボタンを押せば,インプットを変更して実行できる👌個人的には テスト状態という日本語訳が微妙で気付きにくいように思う💨

デプロイして実行した AWS Step Functions ワークフローのトラブルシューティングに TestState APIを使うことが多く,複雑なワークフローを開発しているときに特に便利だな〜と感じる❗️

TestState API を自動テストに活用する

AWS Compute Blog のブログ記事 Accelerating workflow development with the TestState API in AWS Step Functionsを読んでいたら,Jest から TestState API を実行してレスポンスの nextStatestatusを確認する自動テストに活用する例が載っていて参考になった📝

aws.amazon.com

Terraform で Amazon ECS の fargateTaskRetirementWaitPeriod を設定する

$
0
0

2024年5月17日にリリースされた Terraform AWS Provider v5.50.0で Amazon ECS の「Fargate タスクリタイア待機時間 (fargateTaskRetirementWaitPeriod)」を設定できるようになった.

github.com

デフォルトでは「7日間」に設定されていて,選択肢としては 0日7日14日を設定できる.基本的にはすぐにアップデートを反映しておくと良さそうだけど,Fargate タスクの停止に制約・課題がある場合は長めに設定しておくと良さそう.ちなみにブログ記事には 稀に重大なセキュリティアップデートがある場合は待機時間無しでリタイアさせると書いてある📝

docs.aws.amazon.com

aws.amazon.com

さっそく試す

Amazon ECS の aws_ecs_account_setting_defaultリソースを使って設定する.以下の例では「Fargate タスクリタイア待機時間」0日に設定している👌

resource"aws_ecs_account_setting_default""main"{name  = "fargateTaskRetirementWaitPeriod"value = "0"}

aws ecs list-account-settingコマンド

現時点ではマネジメントコンソールで fargateTaskRetirementWaitPeriodの設定を確認することができず,AWS CLI の aws ecs list-account-settingコマンドを使う必要がある👀

awscli.amazonaws.com

Before(terraform apply実行前)

$ aws ecs list-account-settings --name fargateTaskRetirementWaitPeriod --effective-settings{"settings": [{"name": "fargateTaskRetirementWaitPeriod",
            "value": "7",
            "principalArn": "arn:aws:iam::000000000000:root",
            "type": "user"}]}

After(terraform apply実行後)

$ aws ecs list-account-settings --name fargateTaskRetirementWaitPeriod --effective-settings{"settings": [{"name": "fargateTaskRetirementWaitPeriod",
            "value": "0",
            "principalArn": "arn:aws:iam::000000000000:root",
            "type": "user"}]}

AWS CDK の --exclusively オプションでスタック間の依存関係を考慮せずに実行する

$
0
0

AWS CDK の cdk diffコマンド・cdk deployコマンドで --exclusivelyオプションもしくは -eオプションを指定して実行すると,スタック間の依存関係を考慮せずに指定したスタックのみ操作できる👌実行時間を短くしたり,デプロイの影響範囲を狭めたりするときに使えたりする

-e, --exclusively
Only diff requested stacks, don't include dependencies [boolean]

docs.aws.amazon.com

docs.aws.amazon.com

--exclusivelyオプションなし(デフォルト)

stack.addDependency(stack)を使って InfrastructureBackendFrontendという依存関係のあるスタックを作る.あくまでサンプルとして❗️

sandboxCdkFrontendStack.addDependency(sandboxCdkBackendStack)
sandboxCdkBackendStack.addDependency(sandboxCdkInfrastructureStack)

そして Frontend (SandboxCdkFrontendStack)に対して cdk diffコマンドを実行すると,以下のように依存関係に従って実行できる.実行ログは抜粋している📝

$ cdk diff SandboxCdkFrontendStack
Including dependency stacks: SandboxCdkBackendStack, SandboxCdkInfrastructureStack

Stack SandboxCdkFrontendStack
(中略)
Stack SandboxCdkBackendStack
(中略)
Stack SandboxCdkInfrastructureStack
(中略)

cdk deployコマンドも同じ.

$ cdk deploy SandboxCdkFrontendStack
Including dependency stacks: SandboxCdkBackendStack, SandboxCdkInfrastructureStack

SandboxCdkInfrastructureStack
SandboxCdkInfrastructureStack: deploying... [3/3](中略)

SandboxCdkBackendStack
SandboxCdkBackendStack: deploying... [2/3](中略)

SandboxCdkFrontendStack
SandboxCdkFrontendStack: deploying... [1/3](中略)

--exclusivelyオプションあり

今度は Frontend (SandboxCdkFrontendStack)に対して cdk diff --exclusivelyコマンドを実行すると,以下のように依存関係を考慮せずに指定したスタックのみ操作できる❗

$ cdk diff --exclusively SandboxCdkFrontendStack

Stack SandboxCdkFrontendStack
(中略)

cdk deployコマンドも同じ.

$ cdk deploy --exclusively SandboxCdkFrontendStack

SandboxCdkFrontendStack: deploying... [1/1](中略)

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

$
0
0

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 初期画面

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

jsonplaceholder.typicode.com

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

marmelab.com

marmelab.com

Users 一覧画面

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

marmelab.com

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

marmelab.com

marmelab.com

Posts 登録画面

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

Posts 一覧画面(検索とフィルタ)

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

marmelab.com

ログイン画面

まとめ

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

Viewing all 903 articles
Browse latest View live