AWSのイベントre:Inventの資料が公開されていたので、少しずつ眺めていっています。

正直言って、まあだまだこれらの情報に関しての感度が低いのが実情ではあります。
というのも、結局のところ発表してから実際に現場で使うようになるまでに、多くの場合はそれなりに時間がかかるんですよね。
また、先端のサービス開発をしていると違うのかもしれませんが、まだまだ旧来方式の開発をするケースもままあり、なかなかこれらモダンな技術スタックでの開発となるとお目にかかれないのが正直なところです。

とはいえ、実利はともかく面白そう

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_AWS-reInvent_1206_v1.pdf

特に現在はBedrock周りですね。気になったのはIntelligent Prompt Routing

うまいこと、モデルを使い分けてくれるということなんですけど、どういうアルゴリズムでそのモデルを選ぶんだろう？
それぞれを走らせて結果で判断とかだと結局コストかかってるじゃーん！ってなるのでこの目的からは外れてしまう。
一方で、この結果で満足できるかどうかなんてわかるものだろうか？と思ってしまう。

このあたり、どういう考えになっているのかは気になりますね。

このあたりで述べられているエージェントの機能に関しては、今月のSoftwareDesigneで出ていたHIL（Human in the Loop）エージェント周りでもやっていた話なのかな。

コードを書かなくても、これらの事ができるようになっていくというのはいいことなんだろうけれど、流れが早すぎて手を動かす暇があまりない。。。

今回のサービスアップデートがこの資料上では106件あるが、AI関連がその半分くらいを締めているんですよね。
それを考えると、これらを網羅的に把握するのはやはりなかなか厳しいもので、まずは自分に合いそうなユースケースから攻めていく形かなぁ？

Bedrockをちょっと触ってみないことには始まらないかもしれませんね。

少し前に紹介したDynamoDBの操作ツールであるdynein。実際に少し使い始めています。

dynein
https://github.com/awslabs/dynein

取り込むデータはExcelで作成して、それを元にCSVファイルを作成、dyコマンドで取り込もうとしたのですが、、、CSVファイルの取り込みがイマイチでした。。。

そもそも、カラムとしてリスト形式の値を持つものもあるので、CSV形式だとちょっと無理があったかもしれませんが、それにしてもCSV形式の取り込みとしては少し癖がありそうでした。

というわけでJSON形式での取り込みに変更しました。

エクセル上のデータをJSONへ吐き出す方法に関しては、VBAで書いたのですが、VBAでUTF-8形式のファイルを作成するのって結構面倒なんですね。。。

Sub SaveFileUTF8WithoutBOM(filePath As String, dataString As String)
    Dim adodb1 As Object
    Dim adodb2 As Object

    Set adodb1 = CreateObject("ADODB.Stream")
    Set adodb2 = CreateObject("ADODB.Stream")

    With adodb1
        .Charset = "UTF-8"
        .Open
        .WriteText dataString
        .Position = 3
        With adodb2
            .Type = 1
            .Open
            adodb1.CopyTo adodb2
            .SaveToFile filePath, 2
            .Close
        End With
        .Close
    End With
End Sub

一度、ファイルストリームを開いてから、BOM分だけずらし、その内容をコピーするという、何というかバイナリ操作が入るような。。。

VBAもいまだにこういうことをしないとUTF-8を書けないのだろうか？という気になります。もうちょっと何とかならんのですかね。

SAP資格の模擬試験の中でStepFunctionsに関する問題が出たのだけど、 StandardワークフローとExpressワークフローの違いに関する内容でさっぱりだった。
そもそも、StepFunctionsの認識としてはLambdaを順序を持って呼び出すことができるという程度の認識なので、これを機に再確認してみる。

Step Function Integrations

Step Functions で呼び出すことができるのはLambdaだけでなく

• AWS Batch のジョブ実行
• ECSタスクの実行、完了までの待ち
• DynamoDBへのデータ挿入
• SNS,SQSへのPublish
• EMR、Glue、SageMakerジョブの実行
• 別のStepFunctions実行

ができるようだ。最初の表示画面でも人気の高い順としていくつか出ている

Flow

順次実行だけでなくワークフローの選択肢としていくつか用意されている中からワークフローを構成することができる

このあたり、処理の分岐も少しはかけるので、Lambdaを細かい単位で用意してStepFunctionsでロジックを・・・・なんてできるのかもしれない。
ただ、StepFunctionsのフローもJSON形式でコードに落とすことができるとはいえ、管理面で考えればやはりロジックはロジックとしてソースリポジトリで管理したほうが良いように感じる。

Settings

きっかけとなったワークフローのタイプは、日本語のAWSコンソール上では”タイプ”となっていた

What is Step Functions? – AWS Step Functions (amazon.com)

上記ページでは、Standard と Expressの違いが表にまとめられている

Standard workflows	Express workflows
2,000 per second execution rate	100,000 per second execution rate
4,000 per second state transition rate	Nearly unlimited state transition rate
Priced by state transition	Priced by number and duration of executions
Show execution history and visual debugging	Show execution history and visual debugging based on log level
See execution history in Step Functions	Send execution history to CloudWatch
Support integrations with all services.Support optimized integrations with some services.	Support integrations with all services.
Support Request Response pattern for all servicesSupport Run a Job and/or Wait for Callback patterns in specific services (see following section for details)	Support Request Response pattern for all services

Expressのほうが秒間の同時実行数などが高く、大規模になる。
実行時間の最大長さという比較で考えると、Standardが1年間でExpressが5分となっている。
この最大実効時間が正直ピンと来ないんだけど、StepFunctionsでECSなどのタスクも動かせるのでそうしているのだろうか。

課金体系

面白いなと思ったのが、課金体系の違い。
Standardが状態の変化（Stepの移行回数）で課金されるのに対し、Expressは実行回数や実行時間、メモリ消費量などで決まるということだった。

Standardの場合は状態が変わらなければ、最長1年まで実行可能で料金一定と考えると、処理内容によってはリーズナブルな運用ができるのかもしれないな？と思った。
ただ、StepFunctionsに対する課金としてはそうなのかもしれないけれど、それだけの長期間、何かの処理を走らせるのかと考えると別途お金が掛かりそうだなぁとも思った。

設定などを見てみると、いろいろな選択肢が書かれていて、これはやはり大変だなと改めて思ってしまう毎日だ。

AWSのサービスの一つとして時系列データを扱うTimestreamがある

Amazon Timestream（完全マネージド型の時系列データベース）| AWS

IoTなど、データが時刻を伴って送られてくる場合に利用されるようで、いわゆる時系列DBというやつだ。

DynamoDBみたいなものに保持するのと比較して考えると、時系列データ向けの分析関数などが組み込まれていて、データのトレンドやパターンを特定するのに役立つとある。

IoTに限らず、時系列であれば良いのでログデータみたいなものでもいいのかもしれないな、と仕事でDynamoDBにぶち込んでいるデータを、実はTimestreamに入れた方がいいんじゃないだろうか？と思い始めている。

DynamoDBはNoSQLデータベースとしてはいいのだろうけれど、なにぶんクエリや分析をするプラットフォームとして考えると貧弱すぎる。。。というか全然出来ない。

ただ、Timestreamに入れたデータの活用方法ってどうするんだろう？ってのがピンときていない。
分析関数が備わっているわけなので、Timestream上でクエリを発行して分析するの？
ダッシュボードみたいなものを作ろうとした場合は何が使えるんだろうか？

このあたりがどうもなぁ

先のTimestreamのサイトを見る限りでは、AWSサービスの中ではQuickSightを使ったりしている。
SageMakerに読み込ませるという。。。Grafanaの文字がある。

というわけで、Grafanaとの連携の例を探してみる

Amazon TimestreamのデータをGrafanaで可視化してみた | DevelopersIO (classmethod.jp)

さすがクラメソ。期待に答えてくれる。
気温や湿度、CO2などの情報に関してはグラフにし易いけれど、地点別に表示をするなど、見せ方という意味においては私自身の知見が足りない。
このあたり、うまいこと表現手段というものを身に着けたいところだ。

BlackBeltの資料もあったので、合わせて読んでおこう

20201216 AWS Black Belt Online Seminar Amazon Timestream | PPT (slideshare.net)

DynamoDBを仕事で使っていますが、テストデータのインポートや本番データの移行とかを考えたときに、CSVなどで管理してやりたいな、と思いました。

調べてみると、dyneinというものがあるそうで使ってみた

GitHub – awslabs/dynein: DynamoDB CLI written in Rust.

Install & Settings

Download binaries

ツール自体はRustで書かれている単独のファイル。
それぞれの環境で必要となるバイナリをダウンロードします

GitHub – awslabs/dynein: DynamoDB CLI written in Rust.

Setup AWS CLI

各環境にあったAWS CLI をダウンロード、インストールします

AWS コマンドラインインターフェイス（CLI: AWSサービスを管理する統合ツール）| AWS (amazon.com)

インストール後、CLIを実行するためのIAMユーザの設定を行います。
このあたりはこちらを参照

AWS CLI バージョン 2 を使用するための前提条件 – AWS Command Line Interface (amazon.com)

ここまでaws-cliの設定ができていれば、基本的には動くはず

> dy --version
dynein 0.3.0

問題なく動いていることが確認できた。

lsコマンドを打ってみると

> dy ls --all-regions
DynamoDB tables in region: ap-northeast-1
  xxxxx
  yyyyy
  zzzzz
DynamoDB tables in region: ap-northeast-1
  No table in this region.
DynamoDB tables in region: ap-northeast-1
  No table in this region.
DynamoDB tables in region: ap-northeast-1
  No table in this region.
DynamoDB tables in region: ap-northeast-1
  No table in this region.
...

全リージョンのDynamoDBテーブルが出てくる・・・というはずなんだけど、なぜかリージョン名が全部同じ表記になっている。
バグっているのだろうか?
–all-regions オプションを外せば、デフォルト設定しているリージョンのテーブル一覧が取得できる

Export

テーブルデータのExportコマンドは基本的に単純。
データをCSV形式で取得するためにはformatオプションをつければ良い

> dy export -t テーブル名 -f csv -o 出力ファイル名 
As neither --keys-only nor --attributes options are given, fetching an item to understand attributes to export...
Found following attributes in the first item in the table:
  - id (Number)
  - name (String)
  - locationY (Number)
  - locationX (Number)
Are you OK to export items in CSV with columns(attributes) above? yes
51 items processed (61911.99 items/sec)% 

出力されたファイルをみると、カラム名付きで値としては文字列がダブルクォートで括られた形式となっている。（カラム名はダブルクォートなし）

Import

インポートするCSVファイルは、Exportした形式と同じ形に揃える必要があるので注意。

> dy import -t テーブル名 -f csv -i ファイル名.csv
1 items processed (6024096.39 items/sec)% 

aws cliが提供している取り込みと異なって、既存データがある場合はアップデートをしてくれる。
なければ新規のレコードを作ってくれるので便利。

データの入れ替えという意味では、CSVにないデータを削除してくれるわけではないので注意が必要。

総入れ替えを実施するのであれば、一度データを削除するかする必要があるがいっそのことテーブルを作り直した方が早いかもしれない

問題点

唯一の問題は、エクセルをCSV出力した際には自動的にダブルクォートで括ってくれたりするわけではないということ。
もちろん、数値だとか文字だとかでの判別もない。

いっそのこと、エクセル上でVBAマクロを使ってCSVファイルを出力するようにしてしまった方が楽かもしれないな、と思い始めている

SSMを用いてEC2へアクセスすることはこれまでもしたことはあったが、利用したことはあっても設定したことはなかったので勉強を兼ねてやってみた

基本的にはこちらに沿って進めてみます
Session Manager を使用して Amazon EC2 インスタンスに接続 – AWS 規範ガイダンス

IAMロールを作成する

まず手始めにIAMロールを作成する。選択肢としてAWSのサービス、EC2を選択して次へを選ぶ。

AmazonSSMManagedInstanceCoreをポリシーとして選択

適当な名前を付けてロールを作成する

EC2インスタンスの構築

接続先となるEC2インスタンスを構築します。
AmazonLinuxであれば最初からSSMのAgentがインストールされているので今回はそれを利用。
構築時には、下記の設定をデフォルトから変えています

ネットワークとしてパブリックIPの自動割り当てを無効化。
セキュリティとしては、SSHでの接続を自分のIPからのみ許可としました。

「高度な詳細」欄にあるIAMインスタンスプロフィールにて先ほど作成したロールを選択します

ちなみに、キーペアは今はRSAとED25519の選択になっていた

ED25519ってあまり馴染みが無い。
どういうケースでどちらを選ぶとよいのかに関しては後ほど調べておきたいところ。

ログの設定をする

SSMでの接続記録を取るためにログを定義しておきます

AWS SystemManager で Session Mangaer を選択肢、「セッションの開始」枠にある「設定を行う」を選択します

CloudWatch logging欄を下記の設定にします

• CloudWatch logging を Enable
• Choose your preferred logging option を Upload session logs にする
• Enforce encryption のチェックを外す
• CloudWatchのロググループを先程作成したものを選択

ここまでで試しにセッションマネージャーからの接続を確認してみると、SSM Agent がオンラインではないという表記になっている

こちらの手順を再確認するとフリートマネージャーを確認するとあるので見てみると、リストに追加したインスタンスが確かに見当たらない。

うーんちょっとピンとこないなぁ。
フリートマネージャーを確認すると、「IAMロール」に関する項目があったので設定してみたが大きくは変わらなかった。

ちなみに、この状態でローカルからSSH接続を試みると下記のエラーとなった

An error occurred (403) when calling the StartSession operation: Server authentication failed: <UnauthorizedRequest><message>Forbidden.</message></UnauthorizedRequest>

サーバーへの到達不能ではなく、認証エラーとなっているのがちょっと気になるところ。

ちなみに、EC2インスタンスの設定を、デフォルトのパブリックIPを持つ形にするとあっさりとSSMでの接続ができた。

ちょっとのこの辺り、まだ理解が曖昧なんだな・・・。
もう少し勉強が必要そうだ

AWS Certified Solutions Architect Professional の勉強を勧めている中で、おもむろに「CodeCommitのサービス終了が発表されたけど、テストに出るかもだからコースの中では教えるよ！」って感じの話が出てびっくりした。

いくつかのサービスに関して、最近別サービスへの以降の案内が出ていました

Amazon CloudSearch から Amazon OpenSearch Service への移行

Amazon Forecast から Amazon SageMaker Canvas への移行方法

これらの案内の中にもありますが、すぐにサービス終了というわけではなく新規の利用受付の停止という扱いでした。

先日、JAWSのEKSワークショップでCloud9が新規の利用を受け付け停止している話が出ていましたが、同じ理由だったようです。

After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit.

While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today,…

— Jeff Barr ☁️ (@jeffbarr) July 31, 2024

I hear you and we are making improvements so this is clearer for customers.

The services I'm referring to are: S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline, and CodeCommit.

— Jeff Barr ☁️ (@jeffbarr) July 31, 2024

対象となるサービスは上記で言及されているのは

• S3 Select
• CloudSearch
• Cloud9
• SimpleDB
• Forecast
• Data Pipeline
• CodeCommit

のようですね。
ただのX投稿なので実際にはもう少し増えるのかもしれません。

そりゃ、これだけサービスをバカスカ出していれば維持にもお金はかかるし、それほど利用者が多くないサービスに関してはそういう決断をするよね、ということはわかる。

確かにCodeCommitを使うかと言われたらGithub使うよね、という気もするのでわからなくもないんだけど結構びっくりした。

比較的新しいサービスに対して、インフラや開発基盤として取り入れたときのリスクの一つとして、こういうサービス終了も考えていかないといけないですね。

更にいうとこのあたり、試験内容にも影響しそうだなぁと思うわけです。
実際のところ、ベストプラクティがう変わるわけなので、試験をどういう形でこれらに対して向き合えばいいのか。
気になるところです。

先日のJAWSイベントで入手した AWS Builder Cards ですが、これまであまりカードゲームをやってこなかったせいなのか、ルールが非常に難しく感じます。

楽しみながら学べる AWS BuilderCards の遊び方、そして日本語化に込めた思い – builders.flash☆ – 変化を求めるデベロッパーを応援するウェブマガジン | AWS (amazon.com)

特に、Buildフェーズで構築したコストを用いてBuyフェーズでアーキテクチャを購入するわけですが、その際のカウントの仕方がちょっと分かりづらいですね。

Buildのエフェクトでカードを引いた際に、引いたカードを用いてデプロイをし直すことが可能だとかルールも微妙に毎年変わっていくとか色々あるようです。

実際に説明をしながらゲームをしている方がいたので見てみて、ようやくなんとなく進め方が分かるようになりました・・・。

ポケカであるようなスリーブを付けて使っていたのがちょっと印象に残りました。
私も100均で買ってこようかな・・・

JAWS-UGが主催しているEKSのワークショップに行った来ました

JAWS-UG コンテナ支部 #27 EKSワークショップ ハンズオン – connpass

ECSにしろEKSにしろKubanetesにしろ、概念的にはもちろん知っているけれど、実業務ではちょこっと触ったことがある程度。
この際なので触りながら学ぶことができればと申し込んでみました。

が、全体的に時間が押してしまった感があっただけでなく、予定していたワークショップが、環境面のトラブルもあって出来ずじまい。

ちょっと残念な結果になってしまいました。
まぁ、有志のユーザーグループによるワークショップなのでしょうがないですね。

実行しようとしていたワークショップ自体は公開されているものなので、ざっと流れを見てどこかでお試ししてみてもいいかもですが、せっかくなのでワークショップでやってみたい気もします。

しかし、あの人数でこの内容をワークショップで実行しようとしていたら、やはり時間が足りなかったのではないかな？という気もしますね。
実際のところはやってみないとわからないですが。

今回、BuilderCardsをもらうことが出来たのでこちらに関してはやり方を学んで見たいところです

Solutions Architect Professional の資格試験勉強をしているわけですが、Big DataのくだりでIoTデバイスとの接続にKinesisを用いている説明が出てきました

あれ？IoTとつなげるのであればIoT Core じゃないのかな？と思ったわけです

IoT Core を用いる場合

デバイスから AWS IoT Core や Amazon Kinesis にデータを取り込む際のベストプラクティス | Amazon Web Services ブログ

上記解説にいくつか、IoT CoreとKinesisの違いが書かれています。

デバイスの接続という観点で考えるのであれば、IoT Core がMQTTに対応していて、KinesisはHTTPSを受ける取ることしかできないというプロトコルの違いが大きそうです。

IoT CoreがHTTPSも受け取ることができるのであれば、Kinesisを使うメリットってなんだろう・・・？

上記ページでのユースケース2で書かれているような、高スループットでデータを取り込むようなシーンではIoT CoreよりKinesis Video Streamのほうがよいと書かれている。

一方で、資格試験の講座ではIoT CoreよりもKinesisの扱いのほうが重要視されているように見えるんですよね

結局

IoTを扱うシーンではIoT Coreが優位にたつが、Kinesisの場合はそれ以外のデータに関しての利用のほうが多く、AnalyticsやFirehoseなどのサービスと組み合わせて行くことができるのが強みということなのかな。

IoT Core のルールアクションでDynamoDBや何ならFirehoseとつなげることもできるみたいなんだけどな

AWS IoT ルールアクション – AWS IoT Core (amazon.com)

あれ。。。Redshiftがいないんだ。