こんにちは、 @kz_morita です。 今回は QuickSight でテンプレートを作成する方法について記載します。 QuickSight のテンプレート機能 QuickSight にはテンプレート機能が用意されています。 テンプレート機能を使うと、分析やダッシュボードをコピーすることができます。 これは例えば、ダッシュボードを開発環境と本番環境などに分けてデプロイする際などに活用することができます。 テンプレート昨日は、AWS コンソールの GUI からは作成することができず CLI 操作となります。 テンプレートの作成 まずは、テンプレートを作成するための JSON ファイルを作成します。 以下のようなファイルを作成します。 { "SourceAnalysis": { "Arn": "arn:aws:quicksight:${REGION}:${AWS_ACCOUNT_ID}:analysis/${TARGET_ANALYSIS_ID}", "DataSetReferences": [ { "DataSetPlaceholder": "DATA_SET_1", "DataSetArn": "arn:aws:quicksight:${REGION}:${AWS_ACCOUNT_ID}:dataset/${DATA_SET_1_ID}" }, { "DataSetPlaceholder": "DATA_SET_2", "DataSetArn": "arn:aws:quicksight:${REGION}:${AWS_ACCOUNT_ID}:dataset/${DATA_SET_2_ID}" } ] } } 中を説明すると、対象の分析とその分析でしようしているデータセットを指定します。 これらのデータは、DataSetReferences は自動生成できるのそのスクリプトも記載します。 $ aws quicksight describe-analysis-definition --aws-account-id ${AWS_ACCOUNT_ID} --analysis-id ${TARGET_ANALYSIS_ID} \ | jq .Definition.DataSetIdentifierDeclarations \ | jq '. | map({ "DataSetPlaceholder": .Identifier, "DataSetArn": .DataSetArn })'` こちらは、aws-cli で describe-analysis-definition を実行すると取得でいる JSON から jq を用いて必要な情報を取得しています。

こんにちは、 @kz_morita です。 AWS が提供する BI ツールである QuickSight にてマルチテナントなど環境を分離する際に参考になりそうな資料をまとめてみました。 資料まとめ 【開催報告】Amazon QuickSight Roadshow 東京 2023 2023 年 8月に行われたイベントの報告レポートです。QuickSight の色々な機能について触れられています。 以下に上記イベントの中のプレゼン資料をいくつかピックアップします。 フォルダとAPIを活用したシングルアカウントでの複数環境運用 フォルダ機能を使って、複数環境を分離して運用する方法について書かれています。 QuickSight におけるアセット管理 こちらは、QuickSight のアセットをコードで管理する方法について書かれています。 たとえば、開発環境と本番環境を用意している場合異なる環境間でアセットをコピーなどしてデプロイすると言った運用が考えられます。 その際に、アセットをコードとして管理されていると運用がしやすくなりそうです。 上記では Template 機能などが紹介されています。 分離された名前空間によるマルチテナンシーのサポート こちらは、公式サイトで QuickSight では名前空間を使って環境を分離する方法がサポートされていることについて説明されています。 Amazon QuickSight 埋め込みハンズオン > イントロダクション こちらは、QuickSight の埋め込み機能を用いてマルチテナントのアプリケーションを作成するハンズオン資料です。 こちらも名前空間を使用して複数環境用意する例がハンズオン形式で紹介されています。 QuickSightの名前空間機能を使ってマルチテナント用に環境を分離させる 上記も名前空間機能を使ってマルチテナント用に環境を分離させる方法について書かれています。

こんにちは、 @kz_morita です。 DynamoDB のキャパシティユニットについて調べたのでまとめます。 DynamoDB のキャパシティユニットについて DynamoDB の料金体系の一つとして、キャパシティユニットという単位での料金課金があります。 キャパシティユニットは以下のような基準で消費されます。 Read 読み込みのキャパシティユニットは、読み込むDynamoDB のアイテム 4KB ごとに消費されます。 また、読み込みには以下の種類があり、それぞれ消費するユニットが違います。 (デフォルトは、結果整合性のある読み込みです。) 種類 消費ユニット 強力な整合性のある読み込み 1 トランザクション読み込み 2 結果整合性のある読み込み 0.5 たとえば 1 Item のデータサイズが 6KB で、結果整合性のある読み込みをするとすると 1 Item を Read するのに 1 unit 消費します。 ceil(6KB / 4KB) * 0.5 = 2 * 0.5 = 1 トランザクション読み込みであれば、 ceil(6KB / 4KB) * 2 = 2 * 2 = 4 となります。

こんにちは、 @kz_morita です。 Scala から AWS の パラメータストアのデータを読むために実装したのでメモです。 前提 Scala から AWS のリソースにアクセスするために aws-sdk を使用します。build.sbt に以下のように依存を追加します。 libraryDependencies ++= Seq( "software.amazon.awssdk" % "ssm" % "2.17.196" ) また、Scala を ECS などで動かす場合には、SSM Parameter Store にアクセスできる IAM Policy を付与する必要があるので事前に追加しておきます。 以下のような Policy が必要となります。 { "Effect": "Allow", "Action": [ "ssm:GetParameter" ], "Resource": [ "arn:aws:ssm:{REGION}:{ACCOUNT_ID}:parameter:/example/parameter" ] } 実装 awssdk に、SSMClient があるのでそちらを使います。 SsmClient には同期的なバージョンと、非同期用のバージョンの２つがあります。 SsmClient SsmAsyncClient Scala で Future を使って非同期処理をするのであれば、後者の SsmAsyncClient を使用します。 両方の Client には、builder が用意されているので、それを利用します。

こんにちは， @kz_morita です。 データを見る際にデータの傾向を把握するための統計量をだすことはよくあり，pandas などであれば，DataFrame の describe メソッド を呼び出せば以下のようなデータを確認することができます． count: 要素数 unique: ユニークな要素数 top: 最頻値（mode） freq: 最頻値の出現回数 mean: 平均 std: 標準偏差 min: 最小値 max: 最大値 50%: 中央値（median） 25%, 75%: 1/4分位数、3/4分位数 以上のような統計量を，Amazon の Athena (Presto) で表示する方法についてまとめます． Presto で統計量をだす Amazon Athena では，Presto という，オープンソースの分散型SQLエンジンがしようされているため，Athena で分析などを行う際は基本的に Presto のドキュメントをみていくことになります． Presto Documentation データとしては，以下のようなユーザーテーブルを想定します． users user_id name age gender 1 Taro 24 Male 2 Hanako 30 Female 3 Bob 35 Male 4 Alice 15 Female 5 Taro 34 Male count: 要素数 要素数をだすためには，count を使用します．

こんにちは、 @kz_morita です。 今回は、AWS の CodeDeploy の hooks から lambda を実行してみたのでそれについてまとめます。 モチベーション ECSを使って動かしているサービスのデプロイに CodePipeline と CodeDeploy を使っていて, Blue/Green デプロイをしていました。 Blue/Green で本番のタスクセットを切り替えた後に、CloudFront の キャッシュを消したいと思い、CodeDeploy や CodePipeline のドキュメントを調べていたら、CodeDeploy の hooks が使えそうだなということがわかり設定を行いました。 CodeDeploy の hooks について CodeDeploy には、処理の hook を設定できるようになっており、いくつかのタイミングを指定して任意の処理を実行できます。 タイミングは以下のような感じです。 BeforeInstall Install AfterInstall AllowTestTraffic AfterAllowTestTraffic BeforeAllowTraffic AllowTraffic AfterAllowTraffic Install、AllowTestTraffic、AllowTraffic はhooks を指定できないです。 ざっくりと説明すると、 Install が 置き換えタスクセットの作成 AllowTestTraffic がテスト用にトラフィックの切り替え AllowTraffic がトラフィックの切り替え となると思います。それぞれの前後などに任意の処理が挟めることになります。 hooks で実行できるのは、アプリケーションのソースコードリポジトリに含まれる実行可能ファイルか、lambda Function になります。 今回は、lambda function を実行できれば良いのでこちらについてみていきます。 参考: https://docs.

こんにちは、 @kz_morita です。 このブログは S3 + CloudFront の環境に移行してからはローカルで deploy スクリプトを叩く方式をとっていました。 今回 AWS の CodePipeline を用いてデプロイのフローを構築したので手順などをまとめます。 最終的な成果物 最終的には、以下のようなパイプラインを作成しました。 GitHub からソースコードを取得 ソースコードをビルド コードを S3 にデプロイ CloudFront の Cache を Invalidate CodePipeline とは AWS の CodePipeline はパイプラインを作成しソースコードの変更があったときに、ビルドしたりテストしたりデプロイしたりといったフェーズを定義でき、そのフローを自動化することができる AWS のマネージドサービスになります。 このブログでも採用していますが、GitHub の master ブランチにマージ (push) された時に自動でソースコードを取得、ビルド、デプロイをするといったパイプラインが比較的簡単に作成できるのでとても便利です。 具体的な説明は公式サイトを確認してみてください。 https://aws.amazon.com/jp/codepipeline/ Pipeline を CDK で構築する 今回は デプロイのフローを AWS 上に構築するために aws-cdk を用いました。 cdk は、AWS の各種リソースを ソースコードで記述することができるものです。 TypeScript などで記載できバージョン管理なども行えます。（IaC: Infrastructure as Code というやつです） 今回は cdk 自体の解説は行わず、すでに環境が整っている前提とさせてください。

こんにちは、 @kz_morita です。 今回は，AWS CDK を使って Parameter Store のデータを参照する Lambda の環境を構築します． 事前準備 awc-cli のインストールと Credential の設定をしておきます． 自分の環境は以下のような感じです． $ aws --version aws-cli/1.18.69 Python/3.6.9 Linux/5.4.0-72-generic botocore/1.16.19 具体的なインストール方法などは，以下を参考にしてみてください． https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-welcome.html CDK のインストールとプロジェクトの作成 CDK は AWS のインフラをプログラミング言語で記述できるものです．ここでは TypeScript を使ってインフラを構築します． npm install で cdk をインストールします． $ npm install -g aws-cdk $ cdk --versoin 1.105.0 (build 4813992) インストールが完了したら，プロジェクトを作成します． $ mkdir lambda-cdk-sample $ cd lambda-cdk-sample $ cdk init app --language typescript 上記を実行すると以下のようないろいろなファイルが生成されます． . ├── README.md ├── bin │ └── lambda-cdk-sample.

こんにちは、 @kz_morita です。 今回は，さくらVPSでホスティングしていたこのブログを S3 + CloudFront でホスティングするように移行したのでやったことをメモしておきます． やったこと S3 にバケットを作成 CloudFront でキャッシュ設定 CloudFront で エラーの 404 を返すように設定 Lambda@Edge でDefault Rootの設定 ACMでSSL証明書を作成し，CloudFront に設定 お名前.com で cloudfront の URL を設定 S3 にバケットを作成 ブログ用の backet を作成しました．後の工程で CloudFront 以外からのアクセスは許可しない設定にしますがここではパブリック・アクセスをすべて許可する設定にします． バケットを作成したら ローカルで hugo でビルドして後デプロイして動作確認をします． # build $ hugo # deploy $ s3 sync --delete ./public s3://BUCKET_NAME 以下のようなURLにアクセスしてページが表示されることを確認します． https://s3-ap-northeast-1.amazonaws.com/BUCKET_NAME/index.html CloudFront でキャッシュ設定 S3 にデプロイが確認できたら，CloudFrontの設定をします． 基本的には以下の記事の CloudFront で公開 のセクションのとおりに行いました． https://dev.classmethod.jp/articles/cloudfront-s3-customdomain/ ※この段階では独自ドメインの章はやってません． また，前述しましたが，S3を公開設定にしているので CloudFront 側でS3のバケットへのアクセスを制限するために以下のように Restrict Bucket Access を Yes に設定をします．

こんにちは、 @kz_morita です。 E2E Test を Github Actions で実行する際に，VPN 内にある API Server にアクセスする必要があったのですが，Security Group に Github Actions の Public IP を追加する方法でうまく動かすことが出来たので今回はそのことについてまとめます． 背景とか Web Client 側の E2E テストを実施するにあたり，API Server に接続する必要があったのですが，開発環境の API Server は VPN 内からのみアクセスできるようになっていました． そのため，Github Actions から API Server にアクセスすることが出来ず E2E テストが失敗していました． E2E Test 時のみ アクセスすることができるように，Security Group に Github Actions の Public IP を追加する対応をしました． 実現方法 以下のような yaml で Security Group に Github Actions の Public IPを追加することができました. name:E2E Test with Cypress (Node.

こんにちは、 @kz_morita です。 今回は、AWSのネットワーク周りを学ぼうとして以下の本を読んだので感想などを書いていきます。 Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂3版 目次 CHAPTER 1 システム構築をインフラから始めるには CHAPTER 2 ネットワークを構築する CHAPTER 3 サーバーを構築する CHAPTER 4 Web サーバーソフトをインストールする CHAPTER 5 HTTP の動きを確認する CHAPTER 6 プライベートサブネットを構築する CHAPTER 7 NAT を構築する CHAPTER 8 DB を用いたブログシステムの構築 CHAPTER 9 TCP / IP による通信の仕組みを理解する Appendix A パケットキャプチャで通信をのぞいてみる Appendix B ネットワークの管理・運用とトラブルシューティング できるようになること この本を一通りやると、Web サーバーと、DB サーバーからなる簡単なアプリケーションのネットワークを構築できるようになります。(本書の例では WordPress をインストールして動かすところまでを行います) 具体的には、VPCを作成してその中にパブリックサブネットとプライベートサブネットを作成しました。 パブリックサブネットの中に EC2 インスタンスを立てて、インターネットからアクセスできるように、Internet Gateway を設定したり、Web サーバーとして動くように Apache をインストールしました。 プライベートサブネット側には、DB Server として EC2 を構築して、EC2 内からインターネットへ接続できるように、NAT ゲートウェイを構築しました。 このプライベートサブネット内の、DB Server には、踏み台サーバーを通して ssh ログインを行いました。