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使うよね、という気もするのでわからなくもないんだけど結構びっくりした。

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

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