勉強前イメージ TAMみたいなやつ？ 調査 AWSサポート とは AWSのサポートは4つのサポートプランがあり、 それぞれ定額制の料金ではなく、使用分だけ支払う従量制になります。 またプランごとに最低利用料があり、使用量と最低利用料と比べて高い方の金額を払うという仕組みになっています。 サポートプランについて AWSのサポートプランについて以下4つあります。 それぞれ詳細を確認していきます。 ベーシックプラン AWSのアカウントがある全ての人が対象しており、無料で利用できるサービスになります。 サービス状態ダッシュボード・製品 FAQなど利用でき、それ以上になると有償のプランに加入が必要になります。 開発者サポートプラン 個人や学習向けのサポートプランで、有償のプランになります。 利用料金は最低29ドルになります。 このプランでは、日本語サポートを平日9時から18時まで利用できます。 webのサポートから問い合わせができます。 ビジネスサポートプラン ビジネスでの影響があるサービスを利用しているアカウント向けのサポートプランで、 有償プランで最低100ドルになります。 このプランでは、日本語サポートを24時間365日いつでも利用でき、 ビジネスに影響のある障害では初回1時間以内の応答というのもあります。 また、webのサポートをはじめ、電話やメール・チャットでの問い合わせができます。 エンタープライズサポートプラン 団体向けで、ヘビーユーザ向けのサポートプランになります。 有償プランで最低15,000ドルから利用できます。 ビジネスプラン同様、日本語サポートを24時間365日いつでも利用でき、 また緊急時には15分以内に初回応答というのがあります。 問い合わせ方法はwebのサポートをはじめ、電話やメール・チャット、TAM(テクニカルアカウントマネージャー)に連絡することも可能です。 TAMとはAWSに関して技術的な専門知識を有しており、サービスを見ながら問題を解決していき オペレーションやアーキテクチャに対してレビューを行う役割の人です。 このプランのみ、TAMをサポートを受けることができます。 AWSのサポートの内容 お問い合わせ対応 webであればAWSのサポートから問い合わせを行うことができます。 以下がサービスの画面になります。 また、ビズネスプラン以上であれば電話も可能です。 エンタープライズプランになるとTAMのサポートを受けれるので緊急度が高いものはTAMへ連携されることもあります。 サポートフォーラム AWSにはサポートフォーラムというものがあり、ユーザ同士で質問・回答をし合うようなものです。 他の人の質問履歴から問題が解決する可能性もあります。 AWS Trusted Advisor AWS Trusted Advisorというサポートがあり、 システム構成や使用状況を確認し、改善などを提示してくれるサービスになります。 Cost Explorer コストと使用状況レポートから、各サービスごとだったりアカウントごとだったりのコストを見ることができます。 ベストプラクティスの提供 AWSでは各サービスごとにベストプラクティスというのが提供されており、効率の良い使用方法を確認することができます。 例えばEC2であればこちら から確認できます。 1対1で質問への回答 AWSを利用している中のでの問題点や不明点を確認することができ、 ビシネス・エンタープライズプランではこのサポートを時間を問わず利用することができます。 ナレッジセンター こちらの Amazon Web Services Japan 公式チャンネル のAWSサポートから確認することができます。 勉強後イメージ 案外知らないサポート内容があった。 特にベストプラクティスとかほぼ見たことないからきちんと見ていこう。 あと、TAMはサポートの中の1つだったのか。 参考 AWSサポートのご紹介 AWSのサポートプランの種類4つ｜AWSが提供するサポート内容6つ AWSのサポートとは？プランやサポート内容について詳しく解説

はじめに AWS認定試験取得に向けてAWSの知識を整理するためのまとめです。 今回はEC2についてまとめます。 EC2とは Elastic Compute Cloud の略です。 仮想コンピューティング環境を提供するサービスです。 EC2の特徴 Auto Scaling 定義した条件に応じて EC2 インスタンスを自動的に追加または削除できます。 こちらを設定することで耐障害性の向上、アプリケーションの可用性、 コストの削減（必要な時にのみインスタンスが追加されるため）が期待できます。 対応しているOS ・Amazon Linux (RedHatベースのOS) ・Ubuntu ・Windows Server ・CentOS ・Debian など 料金 料金形態 詳細 オンデマンド 実行するインスタンスの時間あたりに対しての料金が発生します。長期利用の契約や前払いの必要はありません。 Savings Plans 1年または3年期間で特定の使用料（USD/時間で測定）を契約する代わりに、オンデマンドより低料金で利用可能となります。詳細は下記参照 リザーブドインスタンス オンデマンド料金より最大72%割引で利用できます。1年または3年の期間で購入できます。(キャパシティが予約される)予約期間中に別のインスタンスファミリーやOSを変更する場合は、コンバーディブルブリザードインスタンスの購入が推奨されています。 スポットインスタンス オンデマンド料金より最大90%割引で利用できます。AWS内の未使用のEC2インスタンスに対して値段をつけて、ユーザの入札価格が現在のスポット価格（可変）を上回っている限りそのインスタンスを利用できる仕組みです。スポット価格が、設定した最高入札額を上回った場合はインスタンスが終了するため、停止を想定したインスタンスの利用を行なう必要があります。 Dedicated Host オンデマンド料金より最大70%割引で利用できます。お客様専用の物理EC2 サーバーです。Amazon や EC2 で Microsoft や Oracle などのベンダー対象ソフトウェアライセンスを使用できるためコスト削減に役立ちます。企業のコンプライアンス(マルチテナントサーバではなく専用サーバで実行する必要がある場合など)要件を満たす場合でも利用できます。 Savings Plans詳細 Savings Plansには３種類あります。 ・Compute Saving Plans 　一番柔軟性があり、Amazon EC2、AWS Lambda、および AWS Fargate 全体の使用量に適用されます。 　EC2インスタンスのインスタンスタイプを変更したり、リージョンを別のところに変えても、 　またはEC2からFargateへ切り替えても引き続き割引が適用されるプランです。 　最大で66%の割引となります。 ・EC2 Instance Savings Plans 　EC2だけを対象とするSavings Plansです。 　最初に選択したリージョンでしか割引は適用されません。 　EC2のインスタンスタイプ、OSなどを変更しても割引が適用され続けます。 　最大で72%の割引となります。 　（RIと同じ割引料金であるため、EC2からサービスを変更しない場合はこちらも検討したほうが良い可能性がある） ・Amazon SageMaker Savings Plans 　Amazon SageMakerだけを対象とするSavings Plansです。 　インスタンスファミリー、サイズ、AZ、AWS リージョン、またはコンポーネントに関係なく、 　SageMaker インスタンスの利用に適用されます。 　最大で64%の割引となります。 （SageMakerとは機械学習モデルを高速に開発、学習、デプロイするための モジュールが用意されているフルマネージド型サービスです） 参考サイト https://aws.amazon.com/jp/products/compute/?nc2=h_ql_prod_cp https://qiita.com/nasuvitz/items/1317495450e91c987cba https://recipe.kc-cloud.jp/archives/321 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-spot-instances.html

概要 AWSのRDSを使ってPostgreSQLへ接続をしてみました。 前提事項 RDSの作成で行うパラメータ設定は、基本的にはすべてデフォルトで行っています。 また、接続方法はEC2インスタンスの踏み台サーバを使ってRDSへ接続します。 早速接続してみる EC2にpsqlクライアントを入れる ・postgresql9.6がインストールされているか確認する 今回はamazon-linux-extraパッケージを使用します [root@ip-10-0-1-10 ~]# amazon-linux-extras list | grep postgre 5 postgresql9.6 available \ 6 postgresql10 available [ =10 =stable ] 41 postgresql11 available [ =11 =stable ] 58 postgresql12 available [ =stable ] 59 postgresql13 available [ =stable ] [root@ip-10-0-1-10 ~]# 使用可能状態なので、インストールしていきます [root@ip-10-0-1-10 ~]# amazon-linux-extras install postgresql9.6 Installed: postgresql.x86_64 0:9.6.22-1.amzn2.0.1 Dependency Installed: postgresql-libs.x86_64 0:9.6.22-1.amzn2.0.1 Complete! 5 postgresql9.6=latest enabled \ [ =9.6.6 =9.6.8 =stable ] [root@ip-10-0-1-10 ~]# psql --version psql (PostgreSQL) 9.6.22 Postgresqlサーバもインストールする psqlが使えるだけではセットアップができません。 セットアップを行うためには、postgresql-serverのインストールもする必要があるので それもインストールしていきます。 [root@ip-10-0-1-10 ~]# yum list | grep postgresql-server postgresql-server.x86_64 9.6.22-1.amzn2.0.1 amzn2extra-postgresql9.6 [root@ip-10-0-1-10 ~]# yum install postgresql-server Installed: postgresql-server.x86_64 0:9.6.22-1.amzn2.0.1 Complete! [root@ip-10-0-1-10 ~]# which postgresql-setup /usr/bin/postgresql-setup Postgreクライアントのセットアップをする [root@ip-10-0-1-10 ~]# /usr/bin/postgresql-setup initdb WARNING: using obsoleted argument syntax, try --help WARNING: arguments transformed to: postgresql-setup --initdb --unit postgresql * Initializing database in '/var/lib/pgsql/data' * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log [root@ip-10-0-1-10 ~]# systemctl start postgresql [root@ip-10-0-1-10 ~]# systemctl status postgresql ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-07-30 14:25:58 UTC; 4s ago Process: 4045 ExecStartPre=/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS) Main PID: 4047 (postmaster) CGroup: /system.slice/postgresql.service ├─4047 /usr/bin/postmaster -D /var/lib/pgsql/data ├─4050 postgres: logger process ├─4052 postgres: checkpointer process ├─4053 postgres: writer process ├─4054 postgres: wal writer process ├─4055 postgres: autovacuum launcher process └─4056 postgres: stats collector process Jul 30 14:25:58 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Star... Jul 30 14:25:58 ip-10-0-1-10.ap-northeast-1.compute.internal postmaster[4047]: ... Jul 30 14:25:58 ip-10-0-1-10.ap-northeast-1.compute.internal postmaster[4047]: ... Jul 30 14:25:58 ip-10-0-1-10.ap-northeast-1.compute.internal systemd[1]: Star... Hint: Some lines were ellipsized, use -l to show in full. psql接続をする -bash-4.2$ psql \ > --host=database-2.c5jqncbegdvz.ap-northeast-1.rds.amazonaws.com \ > --port=5432 \ > --username=postgres \ > --password \ > --dbname=TESTDB Password for user postgres: psql (9.6.22) SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off) Type "help" for help. TESTDB=> 参考 psql を使用した PostgreSQL DB インスタンスへの接続

目的 Node.jsを用いて簡易なWebシステムを構築する。まずは DBを参照して簡単な画面を出すだけ。 環境条件 Node.js実行環境構築 で構築した環境を利用。 構築手順 ec2-userでログイン # rootユーザにスイッチ sudo su - 1.アプリ用のデータ準備 MySQLに必要な設定を実施する。 # MySQLにログイン mysql -uroot -ppassword # DBの作成 create database myappdb; # DBの選択 use myappdb; # テーブルの作成（ID, Name, Priceを含む簡易なテーブル） create table myapptbl1 (id int auto_increment, name varchar(50), price int, primary key (id)); # データの投入 insert into myapptbl1 (name, price) values ('りんご',150); insert into myapptbl1 (name, price) values ('みかん',100); insert into myapptbl1 (name, price) values ('メロン',1000); insert into myapptbl1 (name, price) values ('ぶどう',400); # データの確認 select * from myapptbl1; +------+-----------+-------+ | id | name | price | +------+-----------+-------+ | 1 | りんご | 150 | | 2 | みかん | 100 | | 3 | メロン | 1000 | | 4 | ぶどう | 400 | +------+-----------+-------+ 2.アプリケーション用の初期設定 myapp1というプロジェクトを作成し、必要なモジュールのインストール等を実施する。 #　ディレクトリの作成 mkdir -p /opt/nodejs/myapp1 #ディレクトリの移動 cd /opt/nodejs/myapp1 # npmの初期設定 npm init -y Wrote to /opt/nodejs/myapp1/package.json: { "name": "myapp1", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "keywords": [], "author": "", "license": "ISC" } # expressのインストール npm i -D express npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN myapp1@1.0.0 No description npm WARN myapp1@1.0.0 No repository field. express@4.17.1 added 50 packages from 37 contributors and audited 50 packages in 2.687s found 0 vulnerabilities # express-generatorのインストール npm install -D express-generator npm WARN deprecated mkdirp@0.5.1: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.) npm WARN myapp1@1.0.0 No description npm WARN myapp1@1.0.0 No repository field. # mysql接続用モジュールのインストール npm install --save mysql npm WARN myapp1@1.0.0 No description npm WARN myapp1@1.0.0 No repository field. mysql@2.18.1 added 9 packages from 14 contributors and audited 59 packages in 1.339s found 0 vulnerabilities 3.アプリケーションの開発 こんな形になるようにファイルを作成する。（treeコマンドの結果） myapp1/ ├── app.js ├── node_modules（略） ├── package.json ├── package-lock.json └── views └── index.ejs app.js // 各種ライブラリの呼び出し const express = require('express') const ejs = require('ejs') const mysql = require('mysql') const app = express() // テンプレートエンジンをejsに指定 app.set('ejs', ejs.renderFile) // mysqlへのコネクションオブジェクトの定義 const con = mysql.createConnection({ host: 'localhost', user: 'root', password: 'password', database: 'myappdb' }); // urlへアクセスしてきた際の動作を定義 app.get('/', (req, res) => { 　　　　　　// mysqlへ接続しmyapptbl1の全件のデータを取得し、index.ejsに受け渡しを実施 con.query('select * from myapptbl1', function (err, results, fields) { if (err) throw err res.render('index.ejs', { content: results }) }); }) // 3000番ポートでListenするように設定 app.listen(3000, () => { console.log('server start') }) index.ejs <!DOCTYPE html> <html> <head> <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous"> </head> <body> <div class="container" style="margin-top:50px;"> <table class="table"> <thead class="thead-dark"> <tr> <th scope="col">id</th> <th scope="col">name</th> <th scope="col">price</th> </tr> </thead> <tbody> <% for(let i in content) { %> <tr> <% let obj = content[i]; %> <th> <%= obj.id %> </th> <th> <%= obj.name %> </th> <th> <%= obj.price %> </th> </tr> <% } %> </tbody> </table> </div> </body> </html> # /opt/nodejs/myapp1に移動してアプリケーションを起動 node app.js http://ホスト名:3000 にブラウザからアクセスし、以下のような画面が出れば完了。 次はMySQLへのデータ登録を実施。

目的 Node.jsを用いて簡易なWebシステムを構築することを目的に、まずは動作環境の構築を行う。 環境条件 Node.jsサーバ EC2：t2.micro OS：Red Hat Enterprise Linux 8 (HVM), SSD Volume Type Disk：汎用SSD（GP2） 10GB セキュリティグループの設定等はいい感じに。 構築手順 ec2-userでログイン # rootユーザにスイッチ sudo su - # Node.js用ディレクトリの作成 mkdir -p /opt/nodejs # 作成したディレクトリへ移動 cd /opt/nodejs # Node.jsのモジュールインストール yum module install nodejs:14 # nodeの配置先の確認 which node /usr/bin/node # Node.jsのバージョン確認 node -v v14.16.0 # NPMのバージョン確認 npm -v 6.14.11 この後のアプリケーション開発のために、同サーバにmysqlをインストールしたが、手順については割愛。 8.0.21をインストールし、rootアカウントのパスワードを設定。

初めに API Gateway のプライベート統合を利用してプライベートサブネットにデプロイされたアプリケーションにアクセスします。プライベート統合は VPC 内のリソースに VPC 外からアクセスするための機能です。 API Gateway のプライベートな統合により、VPC 内にある HTTP/HTTPS リソースを VPC 外のクライアントがアクセスできるように簡単に公開できます。プライベート VPC リソースへのアクセスを VPC 境界を超えて拡張するために、プライベート統合で API を作成できます。 プライベート統合を使用するために VPC リンクという機能を使います。 VPC リンクを使用すると、Application Load Balancer または Amazon ECS コンテナベースのアプリケーションなどの、HTTP API ルートを VPC 内のプライベートリソースに接続するプライベート統合を作成できます。 なお VPC リンクを使ったプライベート統合は、ALB のスキームに内部向けを選択しないとうまくいかないようです。最初、インターネット向けでやっていましたが、エラーレスポンスが返ってきました。 以下のチュートリアルの CloudFormation のテンプレートも内部向けになっていました。 Scheme: internal 手順 1. VPC リンクを作成 「HTTP API の VPC リンク」を選択し、アプリケーションをデプロイする VPC を選択します。 サブネットとセキュリティグループを選択し、「作成」をクリックします。 2. ALB を作成 スキームは「内部」を選択します。インターネット向け ALB を作成したところ、ブラウザに {"message": "Service Unavailable"} と表示され、503 エラーが発生しました。ALB のトラフィックを確認したところ、リクエストが ALB まで到達していませんでした。VPC リンクを使ったプライベート統合は、内部向けしか選択できないようです。 VPC と プライベートサブネットを選択します。 ターゲットグループを作成します。種類は IP を選択します。 3. API Gateway の HTTP API を作成 HTTP API の「構築」をクリックします。 API 名を入力し、「次へ」をクリックします。 「次へ」をクリックします。 「次へ」をクリックします。 「作成」をクリックします。 ルートを作成します。「Create」をクリックします。 パスには「/{proxy+}」と入力し、「作成」をクリックします。 プライベート統合を作成します。「統合をアタッチする」をクリックします。 「統合を作成してアタッチ」をクリックします。 統合タイプは「プライベートリソース」を選択します。 以下のように ALB とリスナーを選択します。 VPC リンクを選択し、「作成」をクリックします。 4. エンドポイントを作成 以下のエンドポイントを 4 つ作成します。インターフェース型はすべてプライベート DNS 名を有効化します。 5. Fargate でアプリケーションをデプロイ サービスを作成します。VPC とプライベートサブネット、セキュリティグループを選択します。パブリック IP の自動割り当ては「DISABLED」を選択します。 ALB を選択します。後はデフォルトの設定で進めます。 デプロイが完了しタスクが RUNNING になったら、API の呼び出し URL をブラウザに貼り付けます。 インターネットからプライベートコンテナにアクセスできました。 注意 以下は検証していませんが、定期的にリクエストを送って防ぎたいです。 VPC リンク経由で 60 日間トラフィックが送信されない場合は、INACTIVE になります。VPC リンクが INACTIVE 状態の場合、API Gateway は VPC リンクのネットワークインターフェイスをすべて削除します。これにより、VPC リンクに依存する API リクエストが失敗します。API リクエストが再開すると、API Gateway はネットワークインターフェイスを再プロビジョニングします。ネットワークインターフェイスを作成し、VPC リンクを再度アクティブ化するには、数分かかることがあります。VPC リンクステータスを使用して、VPC リンクの状態を監視できます。 ALB のスキーム インターネット向けと内部向けの違いについて簡単にまとめます。 インターネット向け インターネット向けロードバランサーのノードにはパブリック IP アドレスが必要 インターネット向けロードバランサーの DNS 名は、ノードのパブリック IP アドレスにパブリックに解決可能 インターネット向けロードバランサーは、クライアントからインターネット経由でリクエストをルーティングする 内部向け 内部ロードバランサーのノードはプライベート IP アドレスのみを持つ 内部ロードバランサーの DNS 名は、ノードのプライベート IP アドレスにパブリックに解決可能 内部向けロードバランサーは、ロードバランサー用に VPC へのアクセス権を持つクライアントからのみ、リクエストをルーティングする 共通点 インターネット向けロードバランサーと内部向けロードバランサーは、どちらもプライベート IP アドレスを使用してリクエストをターゲットにルーティングする 確かにパブリックサブネットでコンテナを起動したとき、ノードの IP アドレスがプライベート IP だったのが不思議でした。 参考記事

React server Components (デモ）を Amazon Linux2 で動かす手順です。 本家 - React blog https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html - GitHub https://github.com/reactjs/server-components-demo 原則、上記のREADMEに従っています。 環境 Amazon Linux 2 Amazon Linux 2 AMI (HVM), SSD Volume Type - ami-09ebacdc178ae23b7 (64 ビット x86) / ami-06b31a9cee8dfac33 (64 ビット Arm) EC2(例では ec2-54-95-41-241.ap-northeast-1.compute.amazonaws.com とします) セキュリティ(デモでは4000番ポートを使用するので、ポートを開けておきます) セキュリティルール カスタムTCPルール TCP 4000 0.0.0.0/0 カスタムTCPルール TCP 4000 ::/0 ターミナルからsshでつなぎます。 server-components-demo のインストール 前準備：アップデート $ yum update -y nodeのインストール（Amazon Linux 2 の場合） $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash $ . ~/.nvm/nvm.sh $ nvm install node $ node -e "console.log('Running Node.js ' + process.version)" gitのインストール $ yum install git -y リポジトリから server-components-demo を入手します $ git clone https://github.com/reactjs/server-components-demo.git server-components-demo の初期設定 $ cd server-components-demo/ $ npm install $ npm start 下記のメッセージが表示されたら、Webブラウザで表示してみます。設定が不足しているので、現時点ではエラーになりますが、確認のために見てみましょう。 [0] [nodemon] starting `node --conditions=react-server server` [0] React Notes listening at 4000... [1] Finished running webpack. [1] [nodemon] clean exit - waiting for changes before restart URL Webブラウザで確認（ポートは4000番） http://ec2-54-95-41-241.ap-northeast-1.compute.amazonaws.com:4000/ ※現時点ではエラーメッセージが表示されます。 Application Error Error: connect ECONNREFUSED 127.0.0.1:5432 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1142:16) ターミナルに戻り、 Control + C で終了します。 テストデータを投入 READMEに従って、テストデータを入れていきます（dockerを使う方法です） dockerのインストール（Amazon Linux 2 の場合） $ amazon-linux-extras install docker $ chkconfig docker on $ systemctl enable docker.service $ systemctl restart docker.service docker-composeのインストール $ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose $ chmod +x /usr/local/bin/docker-compose dockerの起動とテストデータの投入（必ず server-components-demo ディレクトリの中で実行してください） $ docker-compose up -d $ docker-compose exec notes-app npm run seed もういちど、Webブラウザから確認します。 http://ec2-54-95-41-241.ap-northeast-1.compute.amazonaws.com:4000/ 今度はエラーにならずに、データが入った状態で表示されています。 試してみる面白いこと READMEからの引用（Google翻訳）です。 サイドバーのメモにカーソルを合わせ、展開/折りたたみの切り替えをクリックして、メモを展開します。次に、メモを作成または削除します。展開されたノートはどうなりますか？ 編集中にノートのタイトルを変更し、既存のアイテムの編集がサイドバーでどのようにアニメーション化されるかに注目してください。リストの途中でメモを編集するとどうなりますか？ 任意のタイトルを検索します。検索入力に検索テキストが残っている状態で、検索テキストと一致するタイトルの新しいメモを作成します。何が起こるのですか？ Slow 3Gで検索し、インラインローディングインジケーターを確認します。 2つの音符を前後に切り替えます。次回それらを再び切り替えるときに、新しい応答を送信しないことに注意してください。 fetch(http://localhost:4000/sleep/....) 通話のコメントを解除するNote.server.jsかNoteList.server.js、人為的な遅延を導入してサスペンスをトリガーします。 コメントを外すだけの場合はNote.server.js、メモを開くたびにフォールバックが表示されます。 コメントを外すだけの場合はNoteList.server.js、最初のページの読み込み時にリストのフォールバックが表示されます。 両方でコメントを外すと、両方が応答するまで表示する新しいものがないため、あまり面白くありません。 新しいサーバーコンポーネントを追加し、の検索バーの上に配置しApp.server.jsます。dbからインポートしdb.serverて使用db.query()し、ノートの数を取得します。メモを追加または削除するとどうなるかを観察します。 ソースコードの場所をもういちど記載します。 GitHub https://github.com/reactjs/server-components-demo

アバン 燃えたらチャンスなので、過去記事ご紹介！ 麻雀のテンパイ判定の話 JavaScriptとnodeの非同期処理の話 計算量オーダーと商売の話 でもって、本書きたいので、出版社の方、声かけて頂けたら企画書書きます！　本編もサクッと書きます！ 既婚で、子持ちで、IT企業に勤める社会人で、40代後半です。奥さんは超頑張り屋です。関係ないけど学校は文系です。で、大昔にプログラマしていたことはあるけれど、基本その後20年間スーツ系のお仕事をしていたので、「サブネットってアレだ。255.255.255.0とかでマスクしてるやつ」くらいのネットワーク知識です。逆にソケットなら使ったことあるけども。 本格的なIaaSが登場したときにはすでにエンジニアから遠い界隈にいたので、「AWSって、さくらインターネットの凄い版？」みたいなぼんやりした印象を持っている、クラウド初心者も甚だしい人でした。でも、AWS資格を取ってみよう、と思ってからきっかり1ヶ月半で11冠取れました。ぱちぱちぱち。まあ、1ヶ月半を「きっかり」と呼ぶかどうかは微妙ですが、どうやれば取れるのか、というあたりをざっくりお話ししようと思います。 ただし、人には向き不向きがあるので、このやり方はあくまで私に合ったやり方に過ぎません。ですから、これはあくまで参考情報です。初期仮説の肥やしにして頂き、おのおのがた、自分なりのやり方を見つけて取り組んでもらえればよいのではないでしょうか。 動機 会社で取得推進が盛り上がっていたんです。それが引き金です。それだけだと身も蓋もないので、もすこし深層を掘ってみると、私、もともとはがっつりエンジニアだったのですね。でも、起業したり完全にITと関係ないビジネスコンサルをやったりで20年弱、ITから遠く離れていたんです。するってーと「そこそこIT分かる」と言ってもまあ、エンジニアにはもちろん、そうでない人にもゆっくり時間をかけないと信じてもらえるわけもなく、なのでまあ「資格でも取ろうかな」という秘めた気持ちがありました。しかも忙しくて先延ばしになりつつあったんで、危機感もありました。 クラウドっていうかIaaSって、私がエンジニアを離れて久しくなってから流行ってきたものなので、正直海の物とも山の物とも知れず、好奇心がうずいた、というのもあります。胡乱な本なのでリンクは張りませんが「クラウドコンピューティングの幻想」なんて本を読んだりもして、「そんなもんかねえ、しらんけど」という偏った認識を持っていたので、「流行って久しいAWSをここらで知ってみるのもいいかな」とも考えたのです。エンジニアの経験があるとは言っても、据え置き型ゲームとか、黎明期のPC用オンラインゲームとかで、まあなんというかコードがっつりの世界しか知らないので、「運用の人」って「なんかTeraTermでgrepしてる人」というイメージしかないという、まあなんか色んな意味で遠い世界だったわけです。 併せて、AWS認定資格自体も、結構流行っている印象です。AWS6冠とかAWS11冠とか、そういう言葉が割と人口に膾炙していて、「なるほど『AWS11冠』って言えば、なんかちょっと頑張った人扱いになるのか」と見受けられたのも、この種目を選んだ理由です。 RTAってほどじゃないけど 色んな人が色んな言い回しで書いていますが、資格って、実務能力とはそんなに強く相関しません。でも無相関でもない。実務がバスケだとしたら、資格は体力測定、というくらいのほどほどの相関です。だから、資格の意義は「特定分野の話が通じる可能性」を示唆してくれる感じですかね。少なくとも、「多少わかってうんうん言ってる人」と「うんうん言ってるけどぜんぜんわかってない人」を見分けるくらいの精度はあると思っています。「話が通じる人」だと証明するために資格を取るんだ、と割り切ってしまえば、さっさとそうなってしまいたいのが人情です。 RTAと言うには初期条件を揃えにくいのでアレですが、最速で全部取ったれ、と決めました。ちなみに「RTA」というのは、Real Time Attackの略で、短い実時間でのゲームクリアを競う遊び方のことです。下調べであれこれググってみて「バッドノウハウ記事に踊らされるな！資格は最短で取れ！」にもちょっと影響されました。 当初の目標は3ヶ月で完走でした。11個、週1個なら3ヶ月。簡単な計算です。だれる日もありそうなので、平均勉強時間は日に2時間くらい、と想定しました。しかし、やっていくうちに、テンションが上がってきました。奥さんもものすごく支援してくれました。超感謝。 結果概要 で、こんなんでましたけど。最終的には当初目標の半分の期間で完走したことになります。 略称 取得日付 点数 正味勉強時間 参考：半月ごとの取得ペース CLF 2021-06-17 830 約5時間 SCS 2021-06-27 767 約14時間 ここまで半月 SAA 2021-07-04 814 約10時間 SOA 2021-07-07 746 約6時間 DVA 2021-07-10 880 約8時間 DOP 2021-07-15 771 約16時間 ここまで次の半月 SAP 2021-07-22 887 約16時間 MLS 2021-07-23 903 約6時間 DAS 2021-07-24 763 約6時間 ANS 2021-07-26 876 約8時間 DBS 2021-07-31 774 約12時間 ここまで最後の半月 点数を書いたので、「ちょいちょいギリギリなの草」とか言われそうですね。まあ否定しません。とはいえ、運にも恵まれて全部一発合格できたので、1ヶ月半で全部いけました。オリンピック連休で3連チャンしたのがいい思い出です。さすがにあれは無理がありました。本当は4連チャンしようと思ったのですが、「次回半額バウチャー」が届くまでに丸一日かかるので、それを待っていたらその間に予約が埋まってしまったのです。次回半額を使いつつ連日受検しようと思うと、夕方6時半にバウチャーが有効になって、すかさず夜8時からの試験を予約、というペースでないといけないのですが、この日は、なんと直近で空いているのが真夜中3時以降しかない、という有様でした。さすがに翌朝からまた出社なのに、夜中の3時に試験を受ける気にはなれません。「11連休で6冠」とか書いていた人がいたので、ネタとしても4連休で4冠なんて書いてみたかったです！　過ぎたことですが、悔しいですねえ。日曜の夜に、今夜は受けられない、というのが判明してストロングゼロを飲んでしまったので、正直1日の猶予は活用できていません。 なお、勉強時間は、中断が入ったり寝落ちもあったりでそんなに精度が高くないと思います。子どもに算数を教える時間は、大体子どもからアポを取ってくれるので突発要因にはならないのですが、それでも数回は号外的なのは発生しましたし、その時間は勘定に入っているかどうか覚えていません。±2割くらいの測定誤差はあると思ってください。合計約107時間。累計すると「うっ」って思いますが、実際スピード最優先で取り組むと、あっという間という印象のほうが強く残っています。 ぼくの（あとから）かんがえたさいきょうの取得順序 Markdownではルビがふれないようなのですが「取得順序」に「ガンダム」というルビをふりたかった気持ちだけ受け取ってください。資格取得なんて第一種情報処理技術者試験以来20数年ぶりということもあって、張り切って色々振り返りをしながら、後知恵も残しているのですが、その中に、こんなメモがあります。 CLF→SAA→DVA→SOA→ ここで猛勉強→DOP→勉強→SAP→勉強→SCS→勉強→ANS→ 息抜き→DBS→DAS→MLS 私は1ヶ月半かかりましたが、正直、現役の若者とか学生なら、この順序なら3週間でいけると思います。「つくれぽ」ならぬ「うけれぽ」が読めると嬉しいです。初め4つと最後3つは、朝?夜?朝?勉強、夜?受検、みたいに、中1日でガンガンいけるはず。 基本的に、前に取った資格の勉強が後に活きてきて、勉強はどんどん加速します。自分の受検間隔がどんどん狭まっているのもそれです。詰め込んだものがこぼれないうちにどんどん受けた方がお得なのでスピード重視はむしろ合格率にプラスです。飲み会で言うところの「おーっとっとっと！　お口でお出迎え！」というやつです（ちがう）。それに加えて順番をちゃんと考えると、勝率はもっと上がります。 そう言えば、略称をふちかましまくっていますが、一応正式名も一覧にしておきましょう。入門＜アソシエイト＜プロフェッショナル＜専門知識の順で、それぞれの中は略称のアルファベット順に並べました。この略称ですが、ちゃんと公式も使っている公認の略称です。しかしなぜクラウドプラクティショナーがCLFなのか、もっとはっきり言えば「Fがどこから出てきたのか」それだけが分かりません。 略称 正式名 和訳名 CLF AWS Certified Cloud Practitioner AWS認定クラウドプラクティショナー DVA AWS Certified Developer - Associate AWS認定デベロッパーアソシエイト SAA AWS Certified Solutions Architect - Associate AWS認定ソリューションアーキテクトアソシエイト SOA AWS Certified SysOps Administrator - Associate AWS認定SysOpsアドミニストレーターアソシエイト DOP AWS Certified DevOps Engineer - Professional AWS認定DevOpsエンジニアプロフェッショナル SAP AWS Certified Solutions Architect - Professional AWS認定ソリューションアーキテクトプロフェッショナル ANS AWS Certified Advanced Networking - Specialty AWS認定高度なネットワーキング専門知識 DAS AWS Certified Data Analytics - Specialty AWS認定データアナリティクス専門知識 DBS AWS Certified Database - Specialty AWS認定データベース専門知識 MLS AWS Certified Machine Learning - Specialty AWS認定機械学習専門知識 SCS AWS Certified Security - Specialty AWS認定セキュリティ専門知識 概ね和訳名はそのまんまなんですが、改めて並べてみると、ANSの据わりの落ち着かなさがすごいですね。そしてやはり「F」。 試験の受け方 自宅受検、素晴らしいです。お風呂ではないです。押し入れのある和室があるので、そこにちゃぶ台を置いて、一切のものを押し入れに詰め込んで、そこで受けました。仕事から帰って、宵の口にほいさっさと受けられる。これなしにはこのペースでの資格取得は絶対にできませんでした。 なお、平日夜に受検するためには、受検言語は日本語でも、試験監督は英語にしないといけません。時差の関係か、英語だと夜中も受けられるのです。英語が苦手でも大丈夫。「プリーズ、タイプ」と言えば、文字チャットで指示をしてくれますので、私は毎回「オッケー」と「サンキュ」と「プリーズ、タイプ」しか言っていません。略して「おっさんプリンタ」です。 あとは、受検日をあらかじめ決めるのが大事です。厳しめに。で、準備不足だと思っても、延期せずに無理を通す。でも、試験予約までしなくても構いません。というのは、特に後半になってくると、前倒しで受けてしまいたくなるものだからです。そんな時、予約まで24時間を切っていると、翌日まで待つことになります。せっかくのテンションを無駄にして、良い結果に資するわけがありません。 試験の受かり方 受かり方大事。Professional以上、7資格の合格基準は75%です。これを「75%の問題にしっかり答えられれば受かる」と解釈すると、安全側に振りすぎた戦術を導いてしまいます。RTA向きな効率からは離れてしまいます。良くても、私程度の素人が数日の勉強で受かろうと思ったら、しっかり分かるのは50%くらいなんじゃないかな、と思います。で、残りの半分が2択まで絞れたら、5分5分ちょいの確率で受かります。でも、さすがにそれは逆に非効率ですよね。私が受けていた期間は、ピアソンのおかわり1杯無料（落ちても１回無料で再受験できる日本向けキャンペーン）が行われていたので、それを使ったとしてもまあ確率8割。ちょっと分が悪すぎます。 私のおすすめは、「2択まで絞ったものを、6割方正解を引けるように鍛える」という方針です。 反復試行の確率で計算すればいいですね。机上の空論ですが、まあモデル化して検証するのは基本なので、一応計算してみましょう。65問の場合です。うち、5問は後述するダミー問題だとします。残り60問のうち、30問は正解が分かるとします。残り30問が2択まで絞れるとします。 では、ここからサルになって、確率50%で正解するとしたら、最頻値のところがギリギリ合格なので、50%よりも多少合格率は高く、約57%になります。確率分布はきれいな左右対称です。想像通りかつ、うれしくないですね。グラフに描くと、fig.1のようになります。縦軸は確率、横軸は正解数。合格基準が青線、正解数ごとの確率分布がオレンジ、点数の高い方からの累計が灰色です。 ▶説明不足のグラフ fig.1 では、2択まで絞れた選択肢を、60%の確率で正解するとしたら？　下のfig.2をご覧ください。縦軸確率、横軸正解数、青いタテ線が、合格ラインです。確率分布がオレンジの線で、点数の高い方から累計したのが灰色の線です。なんと、90%の確率で合格するのです。受け直し1回を勘定に入れれば、合格率は99%を超えます。 ▶説明不足のグラフ fig.2 繰り返します。 半分は確信をもって正解できるようにしよう 残りの半分は、2択まで絞れるようにしよう（2/5択なら、シナリオ1「1つはビンゴ、もう1つが2択」シナリオ2「答えの組が2候補」のどちらかを狙いましょう！　どちらが良いかは、選択肢の作り方によって違うので、問題に合わせましょう） 2択から選ぶとき、6割の確率で正解できるように、推理力を高めよう これで半可通のままでも、合格がもぎ取れます。もちろん、6割あたる、というのを精緻にコントロールすることなどできませんが、合格点の取り方として、こういうイメージを持っておくと、余裕をもって、過剰品質にならずにスピード受検ができるのではないでしょうか。 おまけです。上でちろっと言及した話ですが、AWSの試験では、出題範囲外の問題および出来映えが残念な問題が数問出ます。これは、将来の試験で使う問題を実地テストする目的で混ぜてあるもので、配点が0です。答えても答えなくても0です。だから悩むのは時間の無駄なので、「あ、これかな」と気づいたらフラグも付けずに適当に答えます。SAPなんかは元々範囲が広いので見分けがつきにくいのですが、それでも1問はそれっぽいものに気づきました。 勉強の仕方 他の人々の大半が書いているのとは真逆ですが、「分からない言葉でも調べない」。これがスピードアップのコツです。ググりはじめるときりがありません。真面目に調べるのは、RTA向きじゃありません。正確な知識かどうかは点数とはあまり関係ないので、正解選択肢が選べる程度の間違った理解で構わないのです。資格でなくても、その程度の理解で会話には困りません。手を動かすには困るでしょうけど、手を動かすときにはオンラインヘルプ見るし、ググるし、聞きますよね。だから問題なっしんぐ。試験対策ではなるべく調べません。勝手に解釈するのです。難しげに言えば「内的モデルでカタがつくものは、調べない」。例えば「SQS FIFOってあれね、立ち食いそばの食券置き場ね」という感じ。コンテナとかも、天空の城ラピュタの終盤で出てくる城のバックヤードを想像して、いろんな脳内妄想を重ね合わせています。AWSには滅びの言葉はなさそうですけどね！ 話を戻しましょう。ググらないならどうするか。初めから問題を解きます。選択問題を解いて基準の勝率を超えるのがゲームのルールなので、初めからそれをやるのです。解説書を読んでも麻雀は打てるようにならないのです。私は1資格につき250問と決めて、初手ちんぷんかんぷんでも問題からはじめました。これが賭け麻雀なら大やけどです。なお、どんな問題を解けば良いかというと、 　・本番と似た形式である。（1/4択・2/5択、という点で本番と共通しているのは必須） 　・答えたら、すぐに間違いが分かる。（せめて10問終えたら答え合わせできないとダメです） 　・間違いの理由が何かしら書いてある。 という教材が、良い教材です。 正直、SCSの時は私、まだ全然知見がなくて、中華製の解説なし問題集PDFを買って解いたのですが、かなり苦労しました。解説がちゃんとあるUdemyの英語版問題集を、Chromeの翻訳機能を使って取り組むのが良いと思います。翻訳済み教材なら「AWS WEB問題集で勉強しよう」も良くできていると思います。ただし、2021年7月現在ではDBSに未対応でした。運営者さんには問い合わせて「8月公開」という予定を聞いて「じゃあそれを使って勉強します」と返信したのですが、その後、問い合わせた時点よりも巻きで進めてしまったので、私の受検には間に合いませんでした。 余談の余談にはなりますが、DBAは最後だったので、模擬試験の無料バウチャーがたくさん溜まっていました。SCSの模擬試験が半分くらい公式Exam-Readinessの巻末問題と重複していて「だまされた」と思って以来、ずっと模擬試験は受けていなかったので、無料バウチャーが溜まりまくっていたのです。それで別日に分けて2回受けてみたら、問題セットが2回とも全く同じという衝撃。あれは複数回受けるものじゃないようです。おっと、DBSで熱くなりすぎました。 さて、教材はともかく、問題を解いては、正解選択肢と間違い選択肢の理由を斜め読みします。そして勝手に解釈します。1周したら2周目。2周目は、自分なりの勝手解釈をつぶやきながら解きます。以上。参考書なんて要りません。参考書は、資格取ってから報奨金で買ってください。4択なら資格を取れる程度には解ける、という謎理解にたどり着いてから参考書を読むと、「ああ、そういうことだったのか！」と一読ですらすら入ってきます。逆に参考書を読んでしっかり理解したつもりでも、資格が取れるほど問題が解けるかっていうとそうでもないのですよ、これが。プレゼン術なんかでも、聞き手がすでに知っている情報が7割、というのが、伝わりやすいバランスだと言われます。そういう意味でAWS資格の合格基準は、なかなかいい線をついてくれています。先に詰め込んで、テストに駆け込みましょう。 仕上げに、日本語版の公式Exam Readinessがある資格については、じっくり観ました。嘘です。映像はシークバーをポチポチワープさせて拾い見て、文章と図とサンプル問題・クイズだけ目を通しました。DOP・SAP・SCSはちゃんと勉強になるので、仕上げにおすすめです。知識が増えるわけじゃないけど、全体観が分かって見通しが良くなる感じです。ちなみに、MLSのExam Readinessは変な意味で面白かったですね。サンプル問題の解説が、全然説明になっていなくって、そのくせセクシーボイスで、笑いながら観ました。映像を一番観たのはMLSです。 話を戻しますが、問題をひたすら解く、というスタイルは、特に忙しかったり、突発事象で邪魔されやすかったりする人にお勧めです。正直、問題と選択肢を読んで、選択肢の比較のポイントを絞ったら、別に他の出来事が挟まっても問題ないのです。だから細切れになっても勉強は着実に前進します。 なお、これはちょっぴり高度ですが、特にプロフェッショナルより上のクラスでは、類題を想像しながら解くと、1問で2度美味しいのでおすすめです。また、気のせいかも知れませんが、「類題を想像する」という頭の動かし方をすると、問題の本質にたどり着きやすいように思えました。 テスト中の過ごし方 次に大事なのは、テスト中です。問題が表示されます。選択肢にはラジオボタンかチェックボックスがついていて、クリックで回答します。画面上部にフラグを付けるボタンがあり、画面下部にある「次へ」のリンクで次の問題に進みます。 ここで重要なのは、回答に自信のない場合にフラグを付けるだけではなく、選択肢中に聞いたことのない言葉が出てきた場合もフラグを付けることです。後続の問題を解いているときにその正体が明らかになることがありますが、後からどの問題だったのか探すのは困難です。私の場合は、SAAを受けた時だったと思いますが、「S3 Intelligent-Tiering」なんて、勉強中は一切聞いたことがなかったのですが、このパターンで正体が想像できました。まあ、むしろ、なんでそんな基本的なところに穴があるんだよ、というツッコミまちな感じですね。いずれにせよ、こういうケースを想定すると、フラグの付け方は、前半はフラグを多めに、後半はフラグを少なめに、というバランスが理想です。 1周目は、なるべくリズムを作って、全体の時間の半分を目標に、全て回答します。2周目は「フラグを見直す」です。ここはじっくりと問題を読み直して、推理して解きます。よく言われるように、初見の答えが大体正しいのですが、すでに述べたように、後続の問題から得たヒントで考えが変わることもあります。2周目で、8割方フラグを外すのが理想です。そして3周目、4～5問を粘って考えて、3周目で全てのフラグを外したら、腹をくくって試験終了です。 冒頭そばの結果概要を見て、「3時間の試験に対して勉強時間6時間ってどういうこと？」と思った方もいるかもしれません。しかし、それは制限時間のお話です。DOP・SAPはぼやぼやしてると制限時間を使い切りますし、実際私もDOPは見直しの時間を取れませんでした。でもそれ以外の試験は、見直し含めた3パス合わせても、制限時間の半分以下で終わります。1.5時間の試験に対して勉強時間6時間、と言えばそれほどバカげた数字ではないでしょう。 試験問題は多分作問者ないし作問チームによって多少センスが違うのだと妄想しています。数種類の異なる雰囲気の問題があるんです。文字数多いけどうっすいのもあれば、情報量が多い中にきっちりポイントを仕込んでくるのもあれば、設定の文章の主題から微妙にズレたディテールを聞いてくるのもあります。選択肢の作り方も、複数の2択を組み合わせて4択を構成してくるタイプと、間違い探しみたいにくどい選択肢のいくつかに間違いを仕込んでくるタイプは、見た目は文字ばっかりで似ているのですが、趣味が違うというか、中の人が違うように思えます。そういうタイプごとに、ボブとかチャーリーとか、適当に自分の中で名前をつけておくと、「またお前か」とツッコミながら楽しく取り組めます。 まとめ HACKもTIPSもまだまだありますし、各試験別にも書きたいことはいろいろありますが、あくまでQiitaの記事なので、この辺でおしまいにします。 AWS資格、初めは3ヶ月くらいかけて全部取ろうと思っていたのですが、RTAを意識し始めてから俄然面白くなりはじめました。ぜひ、1ヶ月半なんてぬるいぜ、2週間で充分、とか、そういうフォロー記事を書こうと思って取り組んでもらえたら、楽しいんじゃないかと思います。

はじめに ポートフォリオでAWSでデプロイしたが、Herokuに移行したいという人も多いかと思います。 こちらの記事で紹介したwebアプリをaws ec2にdockerを使って、デプロイをしていたのですが、 無料期間にもかかわらず、200円くらい料金がかかる ちょこちょこオチていた Herokuに移行することにしました。 かかった時間は以外にも1日くらいと、結構スムーズにできました。 ざっくりとですが、備忘録がてら自分が移行作業でやったことを載せます。 herokuにアプリをデプロイ まず、AWSにデプロイしていたアプリをherokuにデプロイします。 Dockerfileやdocker-compose.ymlを変える必要があると思いますので、適宜変えてください。 ちなみに私はこんな感じでHerokuにデプロイしたと思います。 docker-compose.yml version: "3" services: db: image: postgres ports: - '5432:5432' volumes: - ./tmp/db:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: password web: build: context: . dockerfile: Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" tty: true stdin_open: true depends_on: - db ports: - "3000:3000" volumes: - .:/my_app docker-compose.yml FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y nodejs postgresql-client yarn vim RUN mkdir /my_app WORKDIR /my_app COPY Gemfile /my_app/Gemfile COPY Gemfile.lock /my_app/Gemfile.lock RUN bundle install COPY . /my_app COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 CMD ["rails", "server", "-b", "0.0.0.0"] ローカルでdocker compose up -dしたら、 Herokuにデプロイしていきます。 ## コンテナにログイン heroku container:login ## tsumiki-appというアプリを作成 heroku create tsumiki-app ## tsumiki-appというアプリにコンテナをpush heroku container:push web --app tsumiki-app ## postgresを追加 heroku addons:create heroku-postgresql:hobby-dev --app tsumiki-app ## tsumiki-appをrelease heroku container:release web --app tsumiki-app heroku>アプリ>settingで環境変数を定義 RAILS_ENV: production RAILS_SERVE_STATIC_FILES: true SECRET_KEY_BASE: [value] # S3を使っている人はS3のいろいろも追加 $heroku config:get --- みたいにしても設定できますが、疲れてたのでheroku上でやりました(実はコマンド苦手意識) 参考 つづいて、migrateとprecompileをします。 heroku run rails db:migrate --app tsumiki-app heroku run rails assets:precompile --app tsumiki-app アプリをオープン heroku open --app tsumiki-app 無事デプロイできたかと思いましたら、 blocked hostとでたので、それを解消します。 config/application.rbに下記を追加。 config.hosts << "tsumiki-app.herokuapp.com" dbをdumpし、dumpファイルを作る 続いて、dumpファイルを作ります。 AWSで動かしていたpostgresのdb情報をdumpして、先程作ったherokuアプリに流し込みます。 ec2上にいって、下記を実行します。 /usr/local/src/postgresql-12.5/src/bin/pg_dump/pg_dump -U postgres -h `host` -p 5432 `database` -f aws0801.dump ローカルに持ってきます。 scp -i (.pem) myuser@ip-address:(ec2上の持ってきたいdumpがある場所) (dumpを持ってきたいローカルのパス) dumpとかscpとかよくわからない方は調べたら後々幸せになれます。笑 dumpファイルをherokuアプリに流す 流し方は、Heroku推奨のやり方でやってみました↓ s3からHerokuにアップロードする S3にダンプをアップロードして、Herokuにアップロードするやり方が推奨されてました。 すみません。これは頑張ってもできなかったのと、海外のサイトでも、できた人いないっぽかったので、おすすめしません。 直接流す。 heroku pg:psql --app tsumiki-app DATABASE_URL < aws0801.dump まさかのこれでできました。笑 cloudflareでssl化する 最後に、お名前ドットコムでとった、ドメインに、Herokuの方のドメインを紐付けます。 これで無料でssl化することができます。 下記を読めば簡単にできると思います。 詰まったところ 上記で、SSLをフルにしないと、ページが開けません。 フレキシブルにしていたので、開けませんでした。 それでは、お気をつけていってらっしゃい。

はじめに ポートフォリオでAWSでデプロイしたが、Herokuに移行したいという人も多いかと思います。 こちらの記事で紹介したwebアプリをaws ec2にdockerを使って、デプロイをしていたのですが、 無料期間にもかかわらず、200円くらい料金がかかる ちょこちょこオチていた Herokuに移行することにしました。 かかった時間は以外にも1日くらいと、結構スムーズにできました。 ざっくりとですが、備忘録がてら自分が移行作業でやったことを載せます。 herokuにアプリをデプロイ まず、AWSにデプロイしていたアプリをherokuにデプロイします。 Dockerfileやdocker-compose.ymlを変える必要があると思いますので、適宜変えてください。 ちなみに私はこんな感じでHerokuにデプロイしたと思います。 docker-compose.yml version: "3" services: db: image: postgres ports: - '5432:5432' volumes: - ./tmp/db:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: password web: build: context: . dockerfile: Dockerfile command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" tty: true stdin_open: true depends_on: - db ports: - "3000:3000" volumes: - .:/my_app docker-compose.yml FROM ruby:2.7 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y nodejs postgresql-client yarn vim RUN mkdir /my_app WORKDIR /my_app COPY Gemfile /my_app/Gemfile COPY Gemfile.lock /my_app/Gemfile.lock RUN bundle install COPY . /my_app COPY entrypoint.sh /usr/bin/ RUN chmod +x /usr/bin/entrypoint.sh ENTRYPOINT ["entrypoint.sh"] EXPOSE 3000 CMD ["rails", "server", "-b", "0.0.0.0"] ローカルでdocker compose up -dしたら、 Herokuにデプロイしていきます。 ## コンテナにログイン heroku container:login ## tsumiki-appというアプリを作成 heroku create tsumiki-app ## tsumiki-appというアプリにコンテナをpush heroku container:push web --app tsumiki-app ## postgresを追加 heroku addons:create heroku-postgresql:hobby-dev --app tsumiki-app ## tsumiki-appをrelease heroku container:release web --app tsumiki-app heroku>アプリ>settingで環境変数を定義 RAILS_ENV: production RAILS_SERVE_STATIC_FILES: true SECRET_KEY_BASE: [value] # S3を使っている人はS3のいろいろも追加 $heroku config:get --- みたいにしても設定できますが、疲れてたのでheroku上でやりました(実はコマンド苦手意識) 参考 つづいて、migrateとprecompileをします。 heroku run rails db:migrate --app tsumiki-app heroku run rails assets:precompile --app tsumiki-app アプリをオープン heroku open --app tsumiki-app 無事デプロイできたかと思いましたら、 blocked hostとでたので、それを解消します。 config/application.rbに下記を追加。 config.hosts << "tsumiki-app.herokuapp.com" dbをdumpし、dumpファイルを作る 続いて、dumpファイルを作ります。 AWSで動かしていたpostgresのdb情報をdumpして、先程作ったherokuアプリに流し込みます。 ec2上にいって、下記を実行します。 /usr/local/src/postgresql-12.5/src/bin/pg_dump/pg_dump -U postgres -h `host` -p 5432 `database` -f aws0801.dump ローカルに持ってきます。 scp -i (.pem) myuser@ip-address:(ec2上の持ってきたいdumpがある場所) (dumpを持ってきたいローカルのパス) dumpとかscpとかよくわからない方は調べたら後々幸せになれます。笑 dumpファイルをherokuアプリに流す 流し方は、Heroku推奨のやり方でやってみました↓ s3からHerokuにアップロードする S3にダンプをアップロードして、Herokuにアップロードするやり方が推奨されてました。 すみません。これは頑張ってもできなかったのと、海外のサイトでも、できた人いないっぽかったので、おすすめしません。 直接流す。 heroku pg:psql --app tsumiki-app DATABASE_URL < aws0801.dump まさかのこれでできました。笑 cloudflareでssl化する 最後に、お名前ドットコムでとった、ドメインに、Herokuの方のドメインを紐付けます。 これで無料でssl化することができます。 下記を読めば簡単にできると思います。 詰まったところ 上記で、SSLをフルにしないと、ページが開けません。 フレキシブルにしていたので、開けませんでした。 それでは、お気をつけていってらっしゃい。

はじめに AWSの認定試験を受験するにあたり、設問から構成図をイメージできるようになるために以下の教材で学習したので、内容をまとめます。 ① アイコンをダウンロードして作成 ブラウザで「AWS アイコン」で検索し画面のリンクをクリック 「PowerPoint 用ツールキットのダウンロード」をクリック ファイルを解凍してパワーポイント等で構成図を作成する。 ② 3rd partyのツールを利用して作成 アドレスバーで「draw.io」を入力しエンターキーを押下 好きな保存先を選択 好きなファイルを選択し「Create」をクリック(今回は「Blank Diagram」を選択) 一番左下の「+More Shapes...」を選択 AWSを追加してApplyをクリック 試しに作ってみる 参考講座のプレビューの「本講座で作成するWebアプリケーション」から見れる構成図を真似して作成した。 終わりに 設問から構成図をイメージできるようになったと思います。 自分でWebサービスの構成図を作成することで、サービスの構成の理解が深まりました。

はじめに AWSのネットワーキングについて以下の講座および書籍を参考に学習したので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 VPC (Amazon Virtual Private Cloud) 通常の設定方法 VPCを作成(CIDRを設定) サブネットを作成 Gatewayの設定(インターネットの経路) ネットワークACLの設定(トラフィックの許可) Gatewayの設定 パブリックサブネットからインターネットに接続するにはインターネットゲートウェイが必要。 プライベートサブネットからインターネットに接続するにはNATゲートウェイがパブリックサブネットに必要。 ネットワークACLとセキュリティグループ ネットワークACL セキュリティグループ サブネットへのトラフィック制御 インスタンスへのトラフィック制御 ステートレス ステートフル 許可と拒否を設定残りは拒否 許可のみを設定残りは拒否 上から順に適用 全てのルールを適用 VPC Endpoint インターネットを経由せずにAWSサービスにアクセスすることが可能。 ゲートウェイエンドポイント : S3、DynamoDBのみ対応 インターフェースエンドポイント : Private Linkのこと Private Link VPC内にENIが作成され、プライベートIPアドレスが割り当てられる。これによりインターネットを経由せず各サービスにアクセスが可能になる。 VPC Peering 複数のVPCで通信が可能になる。リージョンをまたぐことも可能。 Direct Connect オンプレミスとVPCをVPN接続(仮想的な専用線)ではなく物理的な専用線でつなぐこと。 AWS Managed VPN VPCとオンプレミス間でアンケに暗号化接続を確立する手段。 オンプレミス側にネットワーク機器の用意が必要。 VPC側にCustomer GatewayとVirtual Private Gatewayが必要。 用語集 ステートフル ： インバウンドのみ設定すればアウトバウンドも許可される。 ステートレス : インバウンド設定だけではアウトバウンドは許可されない。 ENI : 仮想ネットワークカードを表す VPC 内の論理ネットワーキングコンポーネント。ネットワークインターフェイスの作成、インスタンスへのアタッチ/デタッチが可能。 ネットワークカード(NIC) : コンピュータなどの機器を通信ネットワーク（LAN）に接続するためのカード型の拡張装置。 Customer gateway : オンプレミス側とVPC側の接続を有効にするためのゲートウェイ Virtual Private Gateway : AWS側のVPN接続を有効にするためのゲートウェイ

最近、AWSの勉強をしていまして、先日AWS Solutions Architect Professionalに合格しました。 そこで、所感と勉強法のシェアができればと思います。 AWS認定試験の構成 AWSが分野別に認定試験を設けており、アーキテクト、運用、デベロッパーのそれぞれの分野での アソシエイトレベル、プロフェッショナルレベルが設定されています。 赤枠内の試験を下から順に受験していきました。AWS界隈では王道の取り方のようです。 https://aws.amazon.com/jp/certification/ 勉強時間・使った教材 私はオンライン教材より紙が好みなので、書籍中心の勉強をしました。 各試験に対し、勉強時間と教材を紹介します。 CLF(クラウドプラクティショナー) 勉強時間：10h程度 使用教材：「一夜漬け AWS認定クラウドプラクティショナー 直前対策テキスト」 テキストの内容からほぼ出題されますので、丸覚えでも大丈夫です。 あまり時間を掛けずにAWSの知識を証明できるので、お忙しい方はこれだけ受けるのもおすすめです。 SAA(ソリューションアーキテクト　アソシエイト) 勉強時間：+40h程度 使用教材①：「この1冊で合格! AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集」 某大手コンサルが出している本のようです。 Amazonレビューで酷評されていますが、網羅性が高く、よい本だと思います。 SAAとSAPの範囲はあまり変わらないので、SAPの勉強をしているときにこの本に戻って理解しなおすこともありました。 使用教材②：「これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版）」 問題演習に使用しました。問題集としては他に書籍も出ているので、あえてこの教材を使う必要もないかなと思いました。。 +αとして、馴染みのないサービスはBlackBeltやサミットの動画を検索して基本を身に付けました。 特にコンテナに関しては全くわからなかったので、いい機会なので動画を見て勉強しました。以下の動画はコンテナ知らない人でも理解できるので、おすすめです。 https://www.youtube.com/watch?v=L4bLDNRSYC8 SAP(ソリューションアーキテクト　プロフェッショナル) 勉強時間：+40h程度 使用教材：「AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説」 他に日本語の教材が見つからず、書籍の中では1択でした。 問題を3周程度しました。 Udemyの問題集も買いましたが、使いませんでした。SAAがしっかり勉強できていれば、この1冊で大丈夫だと思います。 実際の問題 守秘義務もあるので、そこまで詳細には記すことができませんが、ざっくりと。 CLF、SAA、SAPで必要な基礎知識は変わりませんが、1つずつ聞かれることが深くなっていくイメージです。 CLF：Auto Scalingとは何ですか？ SAA：月末に処理量がスパイクするシステムをEC2インスタンス群で構成します。 高負荷に耐えられるAuto Scaling構成はどれですか？ SAP：※下記 以下はSAPの問題の一例です。模試より抜粋しました。 あるソリューションアーキテクトは、ビッグデータアプリケーションのコストを削減する必要があります。 アプリケーション環境は、Amazon Kinesis データストリームにイベントを送信する数百のデバイスで構 成されています。各デバイスは、1 秒あたり 50 KB～450 KB のデータを送信します。シャードは、デー タを処理してその結果を Amazon S3 に保存する AWS Lambda 関数によってポーリングされます。 毎時間、AWS Lambda 関数は結果でデータについて特異点を識別し、これを Amazon SQS キューに配 置する Amazon Athena クエリを実行します。2 つの EC2 インスタンスで構成された Amazon EC2 Auto Scaling グループはキューをモニタリングし特異点を処理する短い (約 30 秒) プロセスを実行しま す。デバイスは、1 時間に平均 10 個の特異値を送信します。 次の中で、コスト削減に最も適切な方法は何ですか。(2 つ選択) 引用元:https://d1.awsstatic.com/ja_JP/training-and-certification/docs-sa-pro/AWS-Certified-Solutions-Architect-Professional_Sample-Questions.pdf 要件を実現不可能な選択肢が2つ、要件を実現できるが最適でない選択肢が1つ、正解が2つのイメージです。 SAPはこのテンションで75問・3時間出題され続けるので、後半は意識を失いかけながら問題を解ききりました。なかなか体力勝負です。 788点で一発合格できましたが、正直、もう一度受ける気力はありません。。 ただ、問題文は長いですが、原則を抑えていれば解けます。 「EC2よりマネージドサービス」、「できるだけ安く」、「サービス停止は最小限で」のような、選択肢同士を比較する観点を身に付ければ、（なんとか）解けるようになります。 結論:AWSの勉強はおすすめです！ この試験の勉強の過程で、一通りAWSの体系的な知識がついたかと思います。 アプリ担当なので、直接インフラの作業やアーキテクティングを行うことは無いですが、インフラご担当と会話する前提知識として大変役に立っています。 例えば、AWSの提唱するベストプラクティスに沿っていない実装がされている場合、どうしてそのような構成なのかの見当がつくようになりました。 その方がアプリの修正量が少ない、とか、その方が安い、とか。 AWS試験はベンダ試験の中では比較的教材が揃っていて、勉強しやすいです。 100h程度の勉強でProfessionalレベルの認定が取れると考えると、コスパのいい試験と言えると思います。 比較対象はCCNPやOracle Goldかと思いますが、それよりは断然取りやすいと感じました。 AWSはしばらくはパブリッククラウドのデファクトスタンダードであり続けるかと思います。 アプリ技術者が勉強しても決して無駄にならないと思うので、ぜひトライしてみてはいかがでしょうか！

Exec Checker で Exec 環境をチェックする jq コマンドをインストールしておきます。実行方法は、以下の通りです。 sh check-ecs-exec.sh <container name> <task id> リポジトリは以下になります。 こちらのチェッカーはユーザーガイドに記載されています。 Amazon ECS Exec Checker を使用した確認 Amazon ECS Exec Checker スクリプトにより、Amazon ECS クラスターとタスクが ECS Exec 機能を使用するための前提条件を満たしていることを確認および検証できます。このツールを使用するには、AWS CLI の最新バージョンが必要であり、jq が使用可能であることが必要です。詳細については、GitHub の Amazon ECS Exec Checker を参照してください。 AWS CLI のバージョンが古い場合 ECS Exec requires the AWS CLI v1.19.28/v2.1.30 or later. と表示されています。 $ sh check-ecs-exec.sh exec-demo 9ef2e3c658e84a65a5c71c1d06b0a892 ------------------------------------------------------------- Prerequisites for check-ecs-exec.sh v0.6 ------------------------------------------------------------- jq | OK (/usr/bin/jq) AWS CLI | OK (/usr/bin/aws) ------------------------------------------------------------- Prerequisites for the AWS CLI to use ECS Exec ------------------------------------------------------------- Pre-flight check failed: ECS Exec requires the AWS CLI v1.19.28/v2.1.30 or later. Please update the AWS CLI and try again? For v2: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html For v1: https://docs.aws.amazon.com/cli/latest/userguide/install-cliv1.html Session Manager Plugin がインストールされていない場合 Session Manager Plugin | Missing と表示されています。 $ sh check-ecs-exec.sh exec-demo 9ef2e3c658e84a65a5c71c1d06b0a892 ------------------------------------------------------------- Prerequisites for check-ecs-exec.sh v0.6 ------------------------------------------------------------- jq | OK (/usr/bin/jq) AWS CLI | OK (/usr/bin/aws) ------------------------------------------------------------- Prerequisites for the AWS CLI to use ECS Exec ------------------------------------------------------------- AWS CLI Version | OK (aws-cli/2.2.25 Python/3.8.8 Linux/4.14.238-182.422.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off) Session Manager Plugin | Missing "enableExecuteCommand": false の場合 Exec Enabled for Task | NO と表示されています。CLI 実行時に --enable-execute-command が必要です。 sh check-ecs-exec.sh exec-demo addfe8f3365c4782879da1bc34864799 ------------------------------------------------------------- Prerequisites for check-ecs-exec.sh v0.6 ------------------------------------------------------------- jq | OK (/usr/bin/jq) AWS CLI | OK (/usr/bin/aws) ------------------------------------------------------------- Prerequisites for the AWS CLI to use ECS Exec ------------------------------------------------------------- AWS CLI Version | OK (aws-cli/2.2.25 Python/3.8.8 Linux/4.14.238-182.422.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off) Session Manager Plugin | OK (1.2.234.0) ------------------------------------------------------------- Checks on ECS task and other resources ------------------------------------------------------------- Region : ap-northeast-1 Cluster: exec-demo Task : addfe8f3365c4782879da1bc34864799 ------------------------------------------------------------- Cluster Configuration | Audit Logging Not Configured Can I ExecuteCommand? | arn:aws:iam::123456789012:role/EC2Role ecs:ExecuteCommand: allowed ssm:StartSession denied?: implicitDeny Task Status | RUNNING Launch Type | Fargate Platform Version | 1.4.0 Exec Enabled for Task | NO 以下は出力の一部を取り出したものですが、Exec に必要な権限がタスクロールに割り当てられているかどうかを検証し、その結果を出力しています。 Task Role Permissions | arn:aws:iam::123456789012:role/ExecRole ssmmessages:CreateControlChannel: allowed ssmmessages:CreateDataChannel: allowed ssmmessages:OpenControlChannel: allowed ssmmessages:OpenDataChannel: implicitDeny このチェッカーを使用するために必要な iam:SimulatePrincipalPolicy という権限がないメッセージが表示されています。 $ sh check-ecs-exec.sh exec-demo 9ef2e3c658e84a65a5c71c1d06b0a892 ------------------------------------------------------------- Prerequisites for check-ecs-exec.sh v0.6 ------------------------------------------------------------- jq | OK (/usr/bin/jq) AWS CLI | OK (/usr/bin/aws) ------------------------------------------------------------- Prerequisites for the AWS CLI to use ECS Exec ------------------------------------------------------------- AWS CLI Version | OK (aws-cli/2.2.25 Python/3.8.8 Linux/4.14.238-182.422.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off) Session Manager Plugin | Missing ------------------------------------------------------------- Checks on ECS task and other resources ------------------------------------------------------------- Region : ap-northeast-1 Cluster: exec-demo Task : 9ef2e3c658e84a65a5c71c1d06b0a892 ------------------------------------------------------------- Cluster Configuration | Audit Logging Not Configured Can I ExecuteCommand? | arn:aws:iam::123456789012:role/EC2Role An error occurred (AccessDenied) when calling the SimulatePrincipalPolicy operation: User: arn:aws:sts::123456789012:assumed-role/EC2Role/i-0427baf184543ab0e is not authorized to perform: iam:SimulatePrincipalPolicy on resource: arn:aws:iam::123456789012:role/EC2Role スクリプトにも記載されていますが、checker に必要な権限は以下の通りです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:GetInstanceProfile", "iam:SimulatePrincipalPolicy", "ec2:DescribeSubnets", "ec2:DescribeVpcEndpoints", "ecs:DescribeClusters", "ecs:DescribeContainerInstances", "ecs:DescribeTaskDefinition", "ecs:DescribeTasks" ], "Resource": "*" } ] } Exec の使用 必要なことは次の 4 点です。 AWS CLI v1.19.28/v2.1.30 のインストール Session Manager Plugin のインストール タスクロールに Exec に必要な権限を設定する タスク実行時に --enable-execute-command を渡す AWS CLI の v2 の最新版をインストールします。 curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip ./aws/install -i /usr/local/aws-cli -b /usr/bin aws --version aws-cli/2.2.25 が v2.1.30 以降のバージョンであるメッセージを確認します。 aws-cli/2.2.25 Python/3.8.8 Linux/4.14.238-182.422.amzn2.x86_64 exe/x86_64.amzn.2 prompt/off Session Manager Plugin をインストールします。 curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm" -o "session-manager-plugin.rpm" sudo yum install -y session-manager-plugin.rpm session-manager-plugin 以下のメッセージを確認します。 The Session Manager plugin was installed successfully. Use the AWS CLI to start a session. タスクロールに以下のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] } --enable-execute-command をオプションで指定してタスクを実行します。 aws ecs run-task \ --launch-type FARGATE \ --cluster exec-demo \ --task-definition exec-demo \ --network-configuration awsvpcConfiguration="{subnets=[subnet-xxxxxx],securityGroups=[sg-yyyyyy],assignPublicIp=ENABLED}" \ --enable-execute-command 上記のコマンドを実行すると、JSON フォーマットが出力されますので、taskArn というキーを見つけます。c61f0147d08749b3842888fa40980807 が ID です。 "taskArn": "arn:aws:ecs:ap-northeast-1:123456789012:task/exec-demo/c61f0147d08749b3842888fa40980807" 以下を実行します。 aws ecs execute-command \ --cluster exec-demo \ --task c61f0147d08749b3842888fa40980807 \ --container exec-demo \ --interactive \ --command "/bin/bash" 成功すると以下のメッセージが表示され、コンテナに入ることができます。 The Session Manager plugin was installed successfully. Use the AWS CLI to start a session. Starting session with SessionId: ecs-execute-command-0f50e6127b6507aea コンテナ内部でアプリケーションにアクセスしてみます。 root@ip-172-31-19-245:/usr/src/app# curl -i localhost:8080 HTTP/1.1 200 OK X-Powered-By: Express Content-Type: text/html; charset=utf-8 Content-Length: 11 ETag: W/"b-Ck1VqNd45QIvq3AZd8XYQLvEhtA" Date: Sun, 01 Aug 2021 01:40:41 GMT Connection: keep-alive Keep-Alive: timeout=5 Hello World 参考記事

はじめに AWSの管理ツールについて、以下の書籍および公式ドキュメントを参考に学習したので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 CloudWatch AWS上でメトリクスやログの収集・監視、イベントの監視を行うためのマネージドサービス。 データを収集し、AWSとオンプレミスのサーバーで実行されるAWSリソース、アプリケーション、およびサービスが統合されたビューをユーザーに公開する。 CloudWatch Logs ログ収集、保存機能を提供するサービス。 CloudWatch Logs Insightsを利用すれば、保存したログデータに対してクエリを発行し分析できる。 CloudWatch Events AWS上のリソースで発生した変更をニアリアルタイムにイベントとして検知する。 EC2、Lambda、Kinesis等のサービスと連携し、イベントをトリガーとした皇族処理を実行可能。 CloudTrail AWS上で発生したAPIアクセスをログに記録するサービス。 AWSのサービスすべてAPIを介して連携するよう設定されており、誰がどのサービスに対してAPIを発行したかを監査ログに残すことができる。 Cloudtrail Insightを利用すれば異常パターンの定義と検出、CloudWatchEventへのイベント送信も可能。 AWS Config AWSのリソース構成管理サービス。 AWSリソースの構成変更を指定されたS3バケットに保存する。 AWS Config Ruleというルールを設定し、違反した構成変更が行われた場合に、ダッシュボードや管理者への通知、修復アクションが可能。 System Manager EC2インスタンスやオンプレミスのサーバー群の運用管理を容易にするための各種サービス。 サービス名 概要 インベントリ インスタンスおよびインストールされたソフトウェア群に関する情報を収集 オートメーション 定期的に実行が必要な運用管理タスクを自動化 実行コマンド インスタンスに対する運用管理タスクを自動化。（レジストリの編集、パッチ適用等） セッションマネージャー マネジメントコンソール経由でインスタンスに対してSSH接続が可能 パッチマネージャー 指定したメンテナンスウィンドウのタイミングでパッチを自動適用 メンテナンスウィンドウ 運用管理タスクを実行するための時間枠をスケジュールリング ステートマネージャー インスタンスに対するサーバーの設定、ウイルス対策、ファイアウォール設定等を保持 パラメータストア DBへの接続文字列等のパラメータを一元管理 Trusted Adviser 利用中のAWS環境をチェックしベストプラクティスに照らした改善アクションの提案を行うサービス。 Personal Health Dashboard 全世界のリージョンで発生したAWSの生涯やパフォーマンスイシューについて確認できるダッシュボード。 License Manager Microsoft、SAP、Oracle、IBM といったベンダーが提供するライセンスの管理を、AWS とオンプレミス環境で行うサービス。 ライセンス管理者は AWS Service Catalog でルールを追加できる。

Cloudformationのテンプレートファイルを記述する際にYAMLの書き方に困ったのでメモ 特に配列の表記など コメント info: description: 普通の行 # description: コメント行 titie: タイトル # ここはコメント 配列とハッシュ インデントでデータ構造を表現する 配列 - aaa - bbb - ccc ハッシュ abc: val1 def: val2 ghi: val3 配列のハッシュ abc: - aaa - bbb - ccc def: - eee - fff - ggg ハッシュの配列 - abc: val1 def: val2 - ghi: val3 jkl: val4 ブロックスタイルとフロースタイル ブロックスタイル（複数行表記）とフロースタイル（1行表記) 通常はブロックスタイルが良いらしいい 1行にまとめたい部分のみフロースタイルがおすすめとのこと # ブロックスタイル - abc - def - ghi # ↓ #フロースタイル [abc, def, ghi] 型 YAMLは次のデータ型を判断する 整数/浮動小数点/真偽値(true,false)/日付/タイムスタンプ 上記以外は文字列 文字列を明示する場合はシングルクォート、ダブルクォート 複数行の文字列の扱い 文字列にもブロックスタイルがある 用途：UserDataを書く場合らしい # パイプを書くと改行が保持される text1: | hogehoge fugafuga foobar

はじめに AWSの移行方式について以下の書籍を参考に学習したので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 移行の方式 DMS (AWS database Migration Service) データベースの意向を支援するサービス。 移行元：オンプレミスおよびAWS環境上のDB 移行先：EC2上のDB、RDS DBエンジンが異なる場合は Scheme Conversion Toolと組み合わせて移行を実施する。 SCT (AWS Schema Conversion Tool) データベースエンジン間でスキーマの変換を行うツール SMS (AWS Server Migration Service) オンプレミス上に存在する仮想環境上のサーバーをAMIとして移行するサービス。 リホスト方式をサポートする。 短い期間で大量のサーバーを移行可能。 Application Discovery Service 移行の準備段階としてオンプレミス環境の情報を収集するツール。 収集された情報は元に移行方式の検討、移行計画の立案に利用される。 Migration Hub 3rd Partyのベンダーが提供する移行サービスも含めて移行元のアプリケーションの情報を収集し、最適な移行サービスを選択する。 仮想サーバーやアプリケーションの情報をインポート可能。 VM Import/Export オンプレミス上に存在する仮想環境上のサーバーをAWS上に移行するサービス。 SMSリリース前は、リホスト方式で主に利用されていた。 VX Export はEC2をオンプレミス上に移行するためのサービス。 Snow Family オンプレミス環境から大量のデータを移行する際に利用 Snowball : テラバイトクラスのデータを10日程度でAWSへ移行可能 Snowball Edge : デバイス内にCPUが搭載されており、EC2やLambdaの実行が可能。データの加工、集約を実施しその結果を移行することが可能。 Snowmobile : ストレージを搭載したトレーラー車。

ブラウザ上で動画を表示し、指定した時間でカット編集する方法をメモしておきます。 動画編集はMoviePyというPythonライブラリを用いることとし、環境はAWSのcloud9で作成します。 全2回の構成で、第1回ではMoviePyを使って動画編集を行えるようにします。 第2回では、javascriptでカットする領域を表示するなどします。 間違い等あった場合は、コメントでご指摘いただけると幸いです。 第1回はこちら。 1. cut.htmlの作成(前回と同じ) まずはcut.htmlを書いておきます。 cut.html {% load static %} <html lang="ja"> <head> <meta charset="Shift-JIS"> <title>video edit</title> <link rel="stylesheet" href="{% static 'main.css' %}"> </head> <body> <h1>カット編集画面</h1> <section class="cut_left"> <video id=video controls src='{{ MEDIA_URL }}{{ record.Original }}'></video> {% for time in cuttime_list %} <div hidden class='cut_starttime'>{{ time.startTime }}</div> <div hidden class='cut_endtime'>{{ time.endTime }}</div> {% endfor %} <div hidden id='video_duration'>{{ video_duration }}</div> <div class="flagBox"> {% for time in cuttime_list %} <div name="cutflag"></div> {% endfor %} </div> <div class="changeTime"> <button id="changeStartTime">カット開始時間変更</button> <button id="changeEndTime">カット終了時間変更</button> </div> <form method="post"> {% csrf_token %} <div class='edit_time'> <input type='number' value=5 min=0 max={{ video_duration }} step='0.01' id='startTime' name='startTime'> <input type='number' value=10 min=0 max={{ video_duration }} step='0.01' id='endTime' name='endTime'> </div> <div class='cut_operation'> <input type="submit" name="cutCanceled" value="キャンセル"> <input type="submit" name="cutReset" id="cutReset" value="元に戻す"> <input type="submit" name="cutExecute" id="cutExecute" value="カットする"> <input type="submit" name="cutFinished" id="cutFinished" value="完了"> </div> </form> <a href="/"><p>戻る</p></a> </section> <script src={% static 'cut.js' %}></script> </body> </html> 2. main.cssの作成 main.css body { color: #333; font-family: Verdana, sans-serif; margin: 10px; } .cut_left { float: left; width: 70vw; } .cut_left video { width: 63vw; } .flagBox{ width:90%; height:10px; background-color: #C0C0C0; margin: 0; margin-top: 20px; position:relative; } .changeTime button { margin-top: 10px; width: 140px; } .edit_time input { margin-bottom: 10px; width: 140px; } main.cssでhtmlの表示を微調整します。 ここで重要なのは".flagBox"の部分です。 flagBoxは、動画の横のサイズと同じ長さのグレーのバーを表示するために記述しています。 最初の"width:90%"は、cut_leftに占める動画の大きさと同じにしています(63vw/70vw=0.9)。これにより、バーの長さが動画の横のサイズと同じになります。 後は高さと色の設定などです。 3. cut.jsの作成 最後に、JavaScriptを記述していきます。 ここでは、カット開始/終了時間の変更や、カットする領域のバー形式での表示を担当します。 3.1 動画の再生 cut.js // videoの取得 let video = document.getElementById('video'); // 自動再生 video.autoplay = false; // ループ video.loop = true; // カット開始/終了時間を格納 let startTimeArray = []; let endTimeArray = []; // 現在の経過時間 video.addEventListener('timeupdate', function(e) { for (let i=0; i<endTimeArray.length; i++){ if (video.currentTime > startTimeArray[i] && video.currentTime < endTimeArray[i]) { video.currentTime = endTimeArray[i]; } } }); 最初の行で、cut.htmlでidを'video'としているタグを取得します。 自動再生=false、ループ=trueとしておきます。 また、カット開始/終了時間を格納しておく配列を作成し、動画再生中にカット開始時間に来たらカット終了時間まで飛ばすようにしています。 3.2 カット開始/終了時間変更ボタンを押したときの挙動 cut.js // カット開始時間変更ボタンを押した時 let changeStartTime = document.getElementById("changeStartTime"); let startTimeNum = document.getElementById("startTime"); changeStartTime.addEventListener('click', function () { startTimeNum.value = Math.round(video.currentTime * 100) / 100; }); // カット終了時間変更ボタンを押した時 let changeEndTime = document.getElementById("changeEndTime"); let endTimeNum = document.getElementById("endTime"); changeEndTime.addEventListener('click', function () { endTimeNum.value = Math.round(video.currentTime * 100) / 100; }); cut.htmlで「カット開始時間変更」ボタンのidを"changeStartTime"、「カット開始時間」のidを"startTime"と指定しています。ボタンをクリックしたとき、「カット開始時間」のvalueを動画の現在時刻に変更しています。 カット終了時間についても同様です。 3.3 カット領域の表示 cut.js // htmlから必要な要素を取得 let startClass = document.getElementsByClassName("cut_starttime"); let endClass = document.getElementsByClassName("cut_endtime"); let flagName = document.getElementsByName("cutflag"); // カットされている時間の集合 let cutBar = []; // 動画再生時間 let duration = parseFloat(document.getElementById('video_duration').textContent); let inverse_duration = 100 / duration; // カット領域の表示 ShowCutArea(); function ShowCutArea() { let startTimeID = "startTime"; let endTimeID = "endTime"; let flagID = "cutFlag"; let startPer = [0]; // 0を入れておく let endPer = [0]; // 0を入れておく for (var i=0; i<startClass.length; i++){ startClass[i].setAttribute("id", startTimeID + i); endClass[i].setAttribute("id", endTimeID + i); startTimeArray.push(document.getElementById(startTimeID + i).textContent); endTimeArray.push(document.getElementById(endTimeID + i).textContent); } for (var i=1; i<=startClass.length; i++){ startPer[i] = startTimeArray[i-1] * inverse_duration; endPer[i] = endTimeArray[i-1] * inverse_duration; flagName[i-1].className = flagID + i; cutBar[i] = document.getElementsByClassName(flagID + i); cutBar[i][0].style.marginLeft = (startPer[i] - endPer[i-1]) + '%'; cutBar[i][0].style.width = (endPer[i] - startPer[i]) + '%'; cutBar[i][0].style.backgroundColor = "#000000"; cutBar[i][0].style.height = 10 + "px"; cutBar[i][0].style.cssFloat = "left"; } } "ShowCutArea"関数でカット領域を表示します。 この中では同じfor文を2度回しています。 1回目のfor文では、カット開始/終了時間を取得しています。 cut.htmlで、カット開始時間に"cut_starttime"のclassを付けて非表示にしていました。 この値を取得するため、classに順番にstartTimeID1, startTimeID2…とIDを振り、startTimeArrayにこのIDのテキストをpushしていきます。 この操作により、startTimeArray, endTimeArrayにカット開始/終了時間を格納できました。 2回目のfor文では、cut.htmlのflagBox(main.cssによってグレーのバーとして表示されている)のうち、黒く表示する部分を決めています。 実際に色を変更しているのは以下の部分です。 cutBar[i][0].style.marginLeft = (startPer[i] - endPer[i-1]) + '%'; cutBar[i][0].style.width = (endPer[i] - startPer[i]) + '%'; cutBar[i][0].style.backgroundColor = "#000000"; 表示領域は%で表したいので、割合を計算してstartPer, endPerに入れています。 黒く表示する部分の左端はカット開始時間から1つ前のカット終了時間を引いた値、黒く表示する部分の長さはカット終了時間からカット開始時間を引いた値になります。 配列の長さだけ繰り返すことで、複数のカット時間に対応できるようになっています。 cut.js全体はこちらです。 順番等、変更している部分があります。 cut.js 'use strict'; // videoの取得 let video = document.getElementById('video'); // 自動再生 video.autoplay = false; // ループ video.loop = true; // カット開始/終了時間を格納 let startTimeArray = []; let endTimeArray = []; // htmlから必要な要素を取得 let startClass = document.getElementsByClassName("cut_starttime"); let endClass = document.getElementsByClassName("cut_endtime"); let flagName = document.getElementsByName("cutflag"); // カットされている時間の集合 let cutBar = []; // 動画再生時間 let duration = parseFloat(document.getElementById('video_duration').textContent); let inverse_duration = 100 / duration; // カット領域の表示 ShowCutArea(); // 現在の経過時間 video.addEventListener('timeupdate', function(e) { for (let i=0; i<endTimeArray.length; i++){ if (video.currentTime > startTimeArray[i] && video.currentTime < endTimeArray[i]) { video.currentTime = endTimeArray[i]; } } }); // カット開始時間変更ボタンを押した時 let changeStartTime = document.getElementById("changeStartTime"); let startTimeNum = document.getElementById("startTime"); changeStartTime.addEventListener('click', function () { startTimeNum.value = Number(Math.round(video.currentTime * 100) / 100); }); // カット終了時間変更ボタンを押した時 let changeEndTime = document.getElementById("changeEndTime"); let endTimeNum = document.getElementById("endTime"); changeEndTime.addEventListener('click', function () { endTimeNum.value = Number(Math.round(video.currentTime * 100) / 100); }); function ShowCutArea() { let startTimeID = "startTime"; let endTimeID = "endTime"; let flagID = "cutFlag"; let startPer = [0]; // 0を入れておく let endPer = [0]; // 0を入れておく for (var i=0; i<startClass.length; i++){ startClass[i].setAttribute("id", startTimeID + i); endClass[i].setAttribute("id", endTimeID + i); startTimeArray.push(document.getElementById(startTimeID + i).textContent); endTimeArray.push(document.getElementById(endTimeID + i).textContent); } for (var i=1; i<=startClass.length; i++){ startPer[i] = startTimeArray[i-1] * inverse_duration; endPer[i] = endTimeArray[i-1] * inverse_duration; flagName[i-1].className = flagID + i; cutBar[i] = document.getElementsByClassName(flagID + i); cutBar[i][0].style.marginLeft = (startPer[i] - endPer[i-1]) + '%'; cutBar[i][0].style.width = (endPer[i] - startPer[i]) + '%'; cutBar[i][0].style.backgroundColor = "#000000"; cutBar[i][0].style.height = 10 + "px"; cutBar[i][0].style.cssFloat = "left"; } } 4. 最後に 以上でブラウザ上で動画のカット編集ができるようになりました。 まだまだ不十分な部分があるので、参考にしながら改良していただければと思います。

やりたいこと S3のファイルPUTをトリガーとしたLambdaでスロットリングエラーが発生した時の挙動の確認 (スロットリングエラーが発生したときのトリガーイベントが消失するのか…) Summary Lambdaのスロットリングが発生してもS3 イベントは消失せず、一定間隔でリトライされる。(リトライ間隔は徐々に伸び、最大5分) リトライされる期間はイベントの最大有効時間の設定で調整(公式開発者ガイドに記載) 前提 検証手順 Lambdaソースコードの修正 Lambda同時実行数、タイムアウト期間の設定 動作確認 1. Lambdaソースコードの修正 Lambda内に70秒の待機を追加し、スロットリングが発生しやすくする。 index.js 'use strict'; const aws = require('aws-sdk'); const s3 = new aws.S3(); exports.handler = async (event) => { //S3から送られたトリガー内容を確認_ console.log(event); const bucket = event['Records'][0]['s3']['bucket']['name']; const key = event['Records'][0]['s3']['object']['key']; console.log(bucket); console.log(key); //S3.copyObjectを実施(params内Bucket,CopySource, Keyは必須) const params = { Bucket: "copied-bucket-210731", CopySource: bucket+'/'+key, Key: key }; //70秒待機 const sleep = () => new Promise(resolve => { setTimeout(() => { resolve(); }, 70000); }); await sleep(); const result = await s3.copyObject(params).promise(); console.log(result); }; 2. Lambda同時実行数、タイムアウト期間の設定 同時実行数: Lambdaの設定>同時実行で同時実行の予約=1に設定 タイムアウト期間: Lambdaの設定>基本設定でタイムアウト=5分に設定 3. 動作確認 ファイルを10個用意し、S3バケットに同時にアップロードする。 Copiedバケットにすべてのファイルがコピーされていることを確認 概ねリトライ間隔に比例して、コピーされている Cloudwatch Metrixよりスロットリングが発生することを確認 投入時に高頻度でスロットリングが発生、リトライ時に処理されることで徐々にスロットリングの値が低下 参考 (クラメソさんの記事はやってる最中に見つけて、ほぼやりたいことやってくれてました…ありがとうございます！)

How to Build a QoS Solution for OTT Services - The Databricks Blogの翻訳です。 ビデオストリーミングサービスにおける品質の重要性 従来の有料TVは活気を失い続けており、コンテンツ所有者は自身のコンテンツライブラリをマネタイズするために、ダイレクトツーコンシューマー(D2C)のサブスクリプションや、広告付きのストリーミングに軸足を置いています。すべてのビジネスモデルが素晴らしいコンテンツを制作し、ディストリビューターにライセンスする企業においては、完全なガラス張りの体験へのシフトは、顧客にコンテンツをデリバリーするためのメディアサプライチェーン、数多くのデバイスとオペレーティングシステムをサポートしたアプリ、請求やカスタマーサービスのようなカスタマーリレーションシップなど、新たな機能が必要となりました。 多くのvMVPD(バーチャル マルチチャンネル ビデオディストリビューター)と、SVOD(ストリーミング ビデオオンデマンド)サービスは月次ベースで更新され、サブスクリプションサービス事業者は彼らの購読者に対して、毎月、毎週、毎日価値を提供する必要があります(AVOD(広告ありビデオオンデマンド)の視聴者にとっては離脱の障壁はさらに低くなります。単純に他のアプリか、チャンネルを開けばいいのです)。一般的なビデオストリーミングの品質問題(バッファリング、レーテンシー、解像度の低下、ジッタリング、パケット損失、ブランクスクリーンなど)は、購読者の解約や、ビデオエンゲージメントの減少など、ビジネスに重大なインパクトを与えます。 ストリーミングを開始すると、オンプレミス、クラウドのサーバーのソース、CDNレベルあるいはISPレベル、さらには視聴者のホームネットワークの転送、あるいは、プレーヤーやクライアントなど、あまりに多くの場所で問題が起き、視聴者体験が損なわれ得ることを理解します。n x 104の同時ストリーミングにおける障害は、n x 105 や n x 106の障害と異なります。リアルワールドのユーザーを再現し、彼らがチェンネルをサーフィングし、アプリをクリックし、同時に異なるデバイスからサインインするなどして、最も冗長性のあるシステムで障害を起こせるようなリリース前のテスト手法は存在しません。TVの性質上、最も重要で人気のあるイベントは最大の視聴者を引き寄せ、事態は最悪なものになります。もしあなたがソーシャルメディアで不満を受け取り始めたら、それらが特定のユーザーに限定されるものなのか、特定の地域なのかあるいは国全体なのか判別できるでしょうか？もし、国レベルであれば、それはすべてのデバイスにおけるものなのか、固有のタイプのものなのか分かるでしょうか(例えば、OEMが古いデバイスのOSをアップデートして、クライアントとの互換性の問題を引き起こした)？ 視聴者体験の品質問題の特定、対策、防御は、ユーザーの数、ユーザーによるアクションの数、そして、体験における引き渡し(サーバー→CDN→ISP→ホームネットワーク→クライアント)の数を考えるとビッグデータの問題となります。サービス品質(QoS)は、これらのデータストリームを意味あるものにするので、問題が何で、どこで、なぜ起きているのかを理解できるようになります。最終的には、何か問題が起きそうか、問題が起きる前にどのように対策が打てるのかの予兆分析に取り組むことになります。 DatabricksにおけるQoSソリューション概要 このソリューションは、QoSシステムを改善したいと考える、あらゆるビデオストリーミングプラットフォームのコアを提供することを狙いとしています。これは、AWSの研究所が提供するAWSストリーミングメディア分析ソリューションをベースとしています。我々は、リアルタイムの洞察と先進的な分析機能の両方のための統合データ分析基盤として、このソリューションをDatabricksの上に構築しました。 Databricksを用いることで、ストリーミングプラットフォームは堅牢かつ信頼性のあるデータパイプラインによって提供される完全かつ最新のデータセットを用いて迅速に洞察を得ることができ、エンドツーエンドの機械学習ライフサイクル管理をサポートするコラボレーティブな環境を用いて、データサイエンスを加速することで新機能の市場投入に要する時間を短縮し、データエンジニアリングとデータサイエンス両方を統合したプラットフォームを持つことで、ソフトウェア開発サイクル全体でのオペレーションコストを削減することができます。 ビデオQoSソリューションのアーキテクチャ 低レーテンシーのモニタリングアラートや、ピーク時のビデオトラフィックに対応するためのスケーラブルなインフラストラクチャのような複雑性に対して、アーキテクチャに対する分かりやすい選択肢はDeltaアーキテクチャでした。複数の種類のパイプライン(ストリーミングとバッチ)を維持することによる運用上の手間に関する欠点を持つLambdaやKappaアーキテクチャのような標準的なビッグデータアーキテクチャは、データエンジニアリングとデータサイエンス両方のアプローチへのサポートが欠如していました。 Deltaアーキテクチャは、組織のすべての種類のデータペルソナががより生産的になれるようにする次世代のパラダイムです。 データエンジニアは、バッチとストリーミングを選択することなしに、継続的かつコスト効率が良いデータパイプラインを構築できます。 データアナリストは、BIの問い合わせに対して迅速に答えとニアリアルタイムの洞察を得ることができます。 データサイエンティストは、再現性のあるエクスペリメントとレポートを円滑にするタイムトラベルのサポートによって、より信頼性のあるデータセットを用いて、より良い機械学習モデルを構築できます。 図1. データパイプラインに対する"マルチホップ"アプローチを用いるDeltaアーキテクチャ Deltaアーキテクチャを用いたデータパイプラインの書き込みは、データに対して順次構造を追加していく複数のレイヤー「マルチホップ」を持つというベストプラクティスに従います。「ブロンズ」テーブル、あるいは取り込みテーブルは通常、ネイティブフォーマット(JSON、CSV、txt)の生データであり、「シルバー」テーブルは、レポーティングあるいはデータサイエンスに使用できるクレンジング後、変換後のデータセットであり、「ゴールド」は最終的なプレゼンテーションレイヤーとなります。 純粋なストリーミングのユースケースにおいては、データフレームを中間Deltaテーブルに永続化するかどうかは、基本的にレーテンシー/SLAとコストのトレードオフ(例：リアルタイムモニタリングのアラート vs 新たなコンテンツに基づくレコメンドシステムの更新)となります。 図2. データフレームをDeltaテーブルに永続化しつつも、ストリーミングアーキテクチャを実現することは可能です このアプローチにおける「ホップ」の数は、視聴者のダウンストリームの数、集計の複雑度(例えば、構造化ストリーミングは複数の集計の連鎖に対して特定の制限を課します)、オペレーションの効率の最大化に直接影響を受けます。 このQoSソリューションアーキテクチャでは、データ処理のベストプラクティスにフォーカスしており、完全なVOD(ビデオオンデマンド)ソリューションではありません。データと分析にフォーカスするために、ハイレベルのアーキテクチャからは「フロントドア」サービスのAmazon API Gatewayのような幾つかの標準的なコンポーネントは除外されています。 図3. QoSプラットフォームのハイレベルアーキテクチャ データを分析可能な状態にする QoSソリューションに含まれる両方のデータソース(アプリケーションのイベントログとCDNログ)はJSONフォーマットを使用しています。これは、複雑なネスト構造を表現でき、交換が容易ですが、スケーラブルではなく、データレイクや分析システムの格納フォーマットとして維持することは困難です。 企業全体で直接検索できるようにするために、ブロンズからシルバーへのパイプライン(「皆がデータを利用できるようにする」パイプラインです)は、あらゆる生のフォーマットをDelta形式に変換し、あらゆる規制に対応するためにデータのマスキングや品質チェックを行うべきです。 ビデオアプリケーションのイベント このアーキテクチャにおいては、ビデオアプリケーションのイベントはKinesisストリームに直接プッシュされ、スキーマに変更を加えることなしに、Deltaの追加専用テーブルに取り込まれます。 図4. アプリケーションイベントの生データフォーマット このパターンを用いることで、Kinesisストリームのスループットをスケールさせる必要なしに、大量の視聴者のダウンストリームで、データを処理することができます。Deltaテーブル(optimizeをサポートしています！)をシンクとして用いることの副次的な効果として、処理のウィンドウがターゲットテーブルのファイル数に影響すること、ビッグデータにおける「小さなファイル問題」を心配する必要はありません。 処理したいイベントの種別を選択できるようにし、パーティショニングできるようにするために、JSONのイベントファイルからタイムスタンプとメッセージの種別を抽出します。イベントに対する単一のKinesisストリームとDeltaの「Events」テーブルを再び組み合わせることで、ピーク時のスケーリングを容易にしつつも、オペレーション上の複雑性を低減することができます。 図5. シルバーテーブルを作成するためにJSONからすべての詳細情報が抽出されます CDNログ CDN(コンテンツデリバリーネットワーク)のログはS3にデリバリーされるので、これらを処理する最も簡単な方法は、追加の設定なしにS3に到着する新たなデータファイルをインクリメンタルかつ効率的に処理するオートローダーを使用することです。 Python auto_loader_df = spark.readStream.format("cloudFiles") \ .option("cloudFiles.format", "json") \ .option("cloudFiles.region", region) \ .load(input_location) anonymized_df = auto_loader_df.select('*', ip_anonymizer('requestip').alias('ip'))\ .drop('requestip')\ .withColumn("origin", map_ip_to_location(col('ip'))) anonymized_df.writeStream \ .option('checkpointLocation', checkpoint_location)\ .format('delta') \ .table(silver_database + '.cdn_logs') ログには、GDPR規制の元では個人情報とみなされるIPが含まれているので、「皆がデータを利用できるようにする」パイプライン」パイプラインでは、匿名化のステップを含める必要があります。別のテクニックを使うことが可能ですが、ここでは単にIPv4の最後のオクテット、IPv6の最後の80ビットを削除することにしました。さらに、このデータセットは、後ほどローカリゼーションのためにネットワークオペレーションセンターで使用する、アクセス元の国やISPプロバイダーなどの情報が拡張されています。 ダッシュボード / バーチャルなネットワークオペレーションセンターの構築 ストリーミング会社は、地理、デバイス、ネットワーク、現在、過去の視聴行動などの新たなセグメントを容易に定義し、セグメントレベルに抽象化する能力を用いて、個人レベルまでトラッキングすることで、可能な限りニアリアルタイムでネットワークのパフォーマンスとユーザー体験をモニタリングする必要があります。マクロレベルでユーザーのストリーミング体験の健康状態をモニタリングし、問題を早期に検知し、対応するために、ストリーミング会社は通信ネットワークからネットワークオペレーションセンター(NOC)の概念を導入しました。最も基本的なところでは、プロダクトチームが迅速かつ容易にサービスの異常を検知、対応できるようにするために、NOCはパフォーマンスのベースラインと現在のユーザーエクスペリエンスを比較できるダッシュボードを提供すべきです。 このQoSソリューションでは、Databricksのダッシュボードを取り込みました。より複雑な可視化を行うためにBIツールを簡単に接続することもできますが、お客様のフィードバックによれば、多くのケースでビルトインのダッシュボードが、ビジネスユーザーに対して洞察を表現する最も迅速な方法とのことでした。 NoCのために集計されたテーブルは、基本的にDeltaアーキテクチャのゴールドレイヤー、CDNログとアプリケーションイベントの組み合わせとなります。 図6. ネットワークオペレーションセンターのダッシュボードの例 ダッシュボードはSQLあるいはPython/Rの変換処理の結果を可視化したものです。それぞれのノートブックは複数のダッシュボードをサポートしているので、複数のエンドユーザーが異なる要件を持っていても、コードを複製する必要はありません。加えて、Databricksのジョブによって、更新をスケジュールすることも可能です。 図7. SQLクエリー結果の可視化 ビデオのロード時間(最初のフレームまでの時間)は、お使いのCDN、この場合はAWSのCloudFrontエッジノードのそれぞれの場所におけるパフォーマンスの理解に役立ちます。これは、複数のCDNにユーザートラフィックを分散させるか、AWSのCloudFrontであればエッジ上のLambdaを用いて動的に接続元を選択する機能を実装するかと言った、KPIを改善するための戦略に直接インパクトを与えます。 ハイレベルでのバッファリング、それによる貧弱なビデオ品質の体験を理解できずにいることは、購読者の解約率に重大な影響をもたらします。さらに、視聴者のエンゲージメントを減少させるような広告に対して、広告提供者はお金を支払いたいとは思わないでしょう。それらの広告はさらにバッファリングを追加することになるので、広告ビジネスにおける収益にもインパクトを与えることになります。この文脈においては、分析者がビデオの品質だけでなく、ブラウザーやアプリケーションのタイプ、バージョンに対する分析が行えるように、アプリケーション側から可能な限りの情報を集取することが重要です。 コンテンツ側では、アプリケーションのイベントが、ユーザーの振る舞いと全体的な体験の品質に関する有用な情報を提供します。ビデオを一時停止した人の何人が実際にそのビデオ、エピソードを最後まで観たのでしょうか？コンテンツの品質が視聴停止の理由でしょうか、あるいはデリバリーの問題でしょうか？もちろん、ユーザーのプロファイル構築だけでなく、解約予測を行うためにすべてのデータソース(ユーザーの行動、CDNやISPのパフォーマンス)を結合することで、さらなる分析が可能となります。 (ニア)リアルタイムアラートの作成 数百万人のユーザーに対するビデオストリーミングから生成されるデータの速度、ボリューム、多様性に対応する際、ダッシュボードの複雑性によって、NOCにおける人間のオペレータがある時点で最も重要なデータや、根本原因の問題に集中することが困難になります。このソリューションにおいては、容易に自動化されたアラートを設定できるので、パフォーマンスが特定の閾値を上回った場合に、ネットワークの人間のオペレータを支援したり、Lambda関数を用いて自動回復プロトコルを実行することもできます。以下のような例が考えられます。 CDNがベースラインよりもはるかに大きいレーテンシー(例：ベースラインの平均よりも10%以上高いレーテンシー)を示している場合には、自動でCDN切り替え処理を実行。 クライアントの一定数以上(例:5%)が再生エラーを報告した際には、プロダクトチームに対して特定デバイスのクライアントにおける問題の可能性を通知。 特定のISPの視聴者が平均のバッファリング、解像度低下の問題に直面した際には、フロントの顧客窓口に対応と問題軽減の方法(例:ストリーミング品質を低く設定)を通知。 技術的観点では、リアルタイムの通知を生成するためには、ストリーミングエンジンにおいてリアルタイムのデータ処理とプッシュ通知のためのパブリッシュ・サブスクライブサービスが必要となります。 図8. Amazon SNSとAmazon SQSを用いたマイクロサービスの統合 このQoSソリューションは、Amazon SNSとAmazon Lambdaとの統合(以下のWebアプリケーションの更新の例を見てください)や他のコンシューマのためのAmazon SQSを用いたAWSにおけるマイクロサービス統合のベストプラクティスを実装しています。カスタムのforeachライターオプションによって、ルールベースエンジンに基づく(例：一定期間における個々のタイプのアプリのエラーのパーセンテージを検証)メールの通知を送るためのパイプラインへの書き込みを分かりやすいものにしています。 Python def send_error_notification(row): sns_client = boto3.client('sns', region) error_message = 'Number of errors for the App has exceeded the threshold {}'.format(row['percentage']) response = sns_client.publish( TopicArn=, Message= error_message, Subject=, MessageStructure='string') # Structured Streaming Job getKinesisStream("player_events")\ .selectExpr("type", "app_type")\ .groupBy("app_type")\ .apply(calculate_error_percentage)\ .where("percentage > {}".format(threshold)) \ .writeStream\ .foreach(send_error_notification)\ .start() 図9. AWS SNSを用いたメール通知の送信 基本的なメールのユースケースに加えて、デモのプレーヤーには、AWS AppSyncを用いてリアルタイムで更新されるウィジェット(アクティブユーザーの数、最も人気のあるビデオ、ビデオを同時に参照しているユーザーの数)が含まれています。 図10. リアルタイム集計によるアプリケーションの更新 このQoSソリューションは、Amazon SQSを用いて追加のコンシューマがプラグインできるようにしてすべての値を更新するのに同様のアプローチ、構造化ストリーミングとAmazon SNSを適用しています。これは大量のイベントを拡張し、分析する際には一般的なパターンとなります。データを一度事前集計しておき、それぞれのサービス(コンシューマ)が自身の下流で意思決定を行えるようにします。 次のステップ: 機械学習 履歴データを人手で理解することは重要ですが非常に遅いものです。未来において、自動で意思決定をしたいと考えた場合には、機械学習アルゴリズムを導入する必要があります。 レイクハウスプラットフォームとして、DatabricksはHyperopt、Horvod、AutoMLをビルトインでサポートしているMLランタイムや、エンドツーエンドの機械学習ライフサイクル管理ツールであるMLflowとの統合などの機能によって、データサエンティストがより優れたデータサイエンスの成果物を生み出すことを支援します。 これまでのカスタマーベースにおいては、QoSソリューションへの拡張可能性にフォーカスしつつも、すでにいくつかの重要なユースケースを探索してきました。 障害ポイントの予測、対策 D2Cのストリーム提供者が多くのユーザーにリーチするほど、サービスの経済的損失に伴うコストは増加します。MLを活用することで、問題がどこで起きそうかを予測し、問題が悪化する前に対策を打つ(例：同時視聴者数のスパイクによって、自動的によりキャパシティのあるCDNに切り替える)ことで、オペレータはレポートから問題の防御に体制を移行することができます。 顧客解約 サブスクリプションサービスの成長に重要なことは、顧客を維持することです。個人レベルのサービス品質の理解によって、解約モデル、顧客障害価値モデルにQoSを追加することができます。さらに、プロアクティブなメッセージやギフトのオファーをテストするために、ビデオ品質問題に遭遇した顧客集団を生成することができます。 DatabricksのビデオストリーミングQoSソリューションを始めてみる ビデオストリーミング体験において一貫性のある品質を提供することは、豊富なエンターテインメントの選択肢によって、移り気な視聴者をあなたのプラットフォームに引き止めるためには最低限必要なことです。多くのビデオストリーミングプラットフォーム環境に対するクイックスタートとして模索した、このQoSリアルタイムストリーミング分析ソリューションを組み込むことで以下のメリットがあります。 視聴者のあらゆるサイズにスケールします。 配信ワークフローのキーパーツにおける品質パフォーマンス問題を迅速に検知します。 新たな自動アラートを作成したり、データサイエンティストが予兆分析や機械学習をできるようにしたいなどの要件や、視聴者を容易にカスタマイズできいるように柔軟かつモジュール化されています。 スタートするためには、Databricks streaming video QoS solutionのノートブックをダウンロードしてください。どのようにして一つのシステムにバッチとストリーミングデータを統合するのかを学びたいのであれば、Deltaアーキテクチャに関するウェビナーをご覧ください。 参考資料 Data Quality Monitoring on Streaming Data Using Spark Streaming and Delta Lake Databricks, AWS, and SafeGraph Team Up For Easier Analysis of Consumer Behavior Automate and Fast-track Data Lake and Cloud ETL with Databricks and StreamSets Databricks 無料トライアル Databricks 無料トライアル

はじめに AWSのAIサービスを勉強するためにBlack Belt Online Seminerを視聴したので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 セミナーの内容 AIサービスは、データを用意するだけでAPIから機械学習を利用できる。(EC2インスタンスを必要としない) 利用する機械学習は、AWSによって最適な実装がされている。 Amazon Recognition 画像・動画の認識サービス。 それぞれAmazon Recognition Image, Amazon Recognition Videoに分かれる。 主な機能 物体、シーン、アクティビティ検出、 顔分析 動線の検出 顔認識 安全でない（不適切な）コンテンツの検出 有名人の認識 画像中のテキスト認識 リアルタイム分析 Amazon Textract PDF、画像のテキストと構造情報を抽出するマネージドサービス。 テキスト、フォーム、テーブルの抽出が可能。 検出結果はJSON形式で出力される。 Amazon Polly テキストを音声に変換する音声認識サービス。 Amazon Transcribe 音声をテキストに変換する音声認識サービス。 Amazon Translate 言語間でテキストを翻訳するためのニューラル機械翻訳サービス Amazon Comprehend 機械学習を使用してテキストの理解に有用な情報を発見、分析する自然言語処理サービス。 キーフレーズ、感情分析、構文、エンティティ、トピックモデル、言語検出を抽出。 Amazon Lex 音声やテキストを使用して対話型インターフェース(チャットボット)を構築するサービス。 Alexaと同じ会話エンジンを活用して高性能の音声認識および言語理解が可能。 Amazon Personalize ユーザー向けにパーソナライズされたレコメンデーションするための機械学習サービス。 Amazon Forecast 過去の履歴から将来を予測する時系列データ予測サービス まとめ：全体像 種類 サービス 概要 静止画・動画認識 Recognition Image Recognition Video Textract 画像認識動画認識 テキスト認識 音声処理 Polly Transcribe テキスト -> 音声 音声 -> テキスト チャットボット Lex 対話型インターフェース 時系列データ予測 Forecast 過去の履歴から将来を予測 レコメンデーション Personalize 機械学習でユーザーごとにレコメンデーションする おわりに 各サービス概要しか記載していませんが、セミナーでは主な機能やユースケース、システムの構成例も紹介していました。試験対策を進めていくうちに必要であれば記載を充実させていきます。

はじめに 本記事では、Terraformで ElastiCache for Redisの検証環境を構築する手順について記載しています。 全体構成図 本環境での ElastiCache for Redisのクラスターモードは無効の構成になります。 事前に読んでおくと良い資料 ElastiCache のBlackBeltの資料 Amazon ElastiCache のリソース Redis クライアントのインストール手順 Terraform のコードと構成 $ tree aws-tf-elasticahe-test-infra aws-tf-elasticahe-test-infra ├── modules │   ├── network │   │   ├── vpc.tf │   │   ├── internet_gateway.tf │   │   ├── subnet.tf │   │   ├── route_table.tf │   │   ├── variables.tf │   │   ├── outputs.tf │   ├── ec2 │   │   ├── instance.tf │   │   ├── user_data.sh │   │   ├── eip.tf │   │   ├── security_group.tf │   │   ├── iam_role.tf │   │   ├── ec2_trust_policy.json │   │   ├── variables.tf │   │   └── outputs.tf │   └── elasticahe │   ├── replication_group.tf │   ├── subnet_group.tf │   ├── security_group.tf │   ├── variables.tf │   └── outputs.tf ├── main.tf ├── provider.tf ├── terraform.tfvars.org ├── variables.tf └── outputs.tf Terraform で構築する各リソース名 リソース 名前(デフォルト) VPC 名 elasticache-test-vpc インターネットゲートウェイ名 elasticahe-test-igw パブリック サブネット名 elasticahe-test-public-a elasticahe-test-public-c プライベート サブネット名 elasticahe-test-private-a elasticahe-test-private-c EC2 インスタンス名 elasticache-test-ec2 EC2 EIP名 elasticache-test-eip EC2 セキュリティグループ名 elasticache-test-ec2-sg EC2 IAM ロール名 elasticache-test-ec2-role elasticahe クラスター名 elasticahe-test-redis elasticahe サブネットグループ名 elasticahe-test-redis-subnet elasticahe セキュリティグループ名 elasticahe-test-redis-sg 事前準備 ・Terraform のインストール ・tfenv のインストール ・Terraform を実行するための IAM のアクセスキーとシークレットキー Terraform の動作確認環境 $ terraform -version Terraform v1.0.0 on darwin_amd64 + provider registry.terraform.io/hashicorp/aws v3.52.0 Terrraform で環境を構築する手順 本手順は、Mac環境で実施することを想定しています。 Terraformのコードをダウンロードします。 git clone https://github.com/okubo-t/aws-tf-elasticahe-test-infra.git Terraform のコードがあるディレクトへ移動します。 $ cd aws-tf-elasticahe-test-infra/ terraform.tfvars ファイルを作成します。 $ cp -p terraform.tfvars.org terraform.tfvars 作成した terraform.tfvars 内の各パラメータを環境に応じて、任意で変更します。(下記のキーはサンプルです。) terraform.tfvars # アクセスキー aws_access_key = "AKIAIOSFODNN7EXAMPLE" # シークレットキー aws_secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" # リージョン aws_region = "ap-northeast-1" # リソース名のプレフィックス prefix = "elasticahe" # リソースの環境 env = "test" # EC2に SSHアクセスする時の送信元 IPアドレス remote_ip = "0.0.0.0/0" # SSH キー名 key_name = "key name" 下記コマンドで、Terraform の初期設定をします。 $ terraform init 各リソースのパラメーターを調整したい場合は、下記のファイルのパラメータを修正してください。 main.tf module "network" { source = "./modules/network" vpc = { name = "${var.prefix}-${var.env}-vpc" cidr = "10.0.0.0/16" } igw_name = "${var.prefix}-${var.env}-igw" public_subnet_a = { name = "${var.prefix}-${var.env}-public-a" cidr = "10.0.1.0/24" } public_subnet_c = { name = "${var.prefix}-${var.env}-public-c" cidr = "10.0.2.0/24" } private_subnet_a = { name = "${var.prefix}-${var.env}-private-a" cidr = "10.0.10.0/24" } private_subnet_c = { name = "${var.prefix}-${var.env}-private-c" cidr = "10.0.20.0/24" } } # get latest ami Id for amazonlinux2 data "aws_ssm_parameter" "amzn2_ami_latest" { name = "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2" } module "ec2" { source = "./modules/ec2" ## network vpc_id = module.network.vpc_id subnet_id = module.network.public_subnet_a_id remote_ip = var.remote_ip ## base ec2_name = "${var.prefix}-${var.env}-ec2" ami_id = data.aws_ssm_parameter.amzn2_ami_latest.value instance_type = "t3.micro" volume_size = 30 key_name = var.key_name } module "elasticahe" { source = "./modules/elasticahe" ## network vpc_id = module.network.vpc_id vpc_cidr_block = module.network.vpc_cidr_block subnet_ids = [ module.network.private_subnet_a_id, module.network.private_subnet_c_id, ] ## base for redis(cluster mode disabled) cluster_name = "${var.prefix}-${var.env}-redis" node_type = "cache.t3.micro" engine_version = "5.0.6" family = "redis5.0" number_cache_clusters = 2 ## not available for t1/t2 instances automatic_failover_enabled = true ## automatic Failover must also be enabled multi_az_enabled = true } 下記コマンドで、環境のデプロイを実行します。 $ terraform apply デプロイ後に出力される Outputsの内容をメモします。(下記の値は例です。) Apply complete! Resources: 23 added, 0 changed, 0 destroyed. Outputs: instance_eip = "xxx.xxx.xxx.xxx" primary_endpoint_address = "elasticahe-test-redis.xxxxx.ng.0001.apne1.cache.amazonaws.com" reader_endpoint_address = "elasticahe-test-redis-ro.xxxxxx.ng.0001.apne1.cache.amazonaws.com" これで、Terraformによる環境の構築は完了です。 下記コマンドで、構築されたAWS環境のコンポーネントを確認できます。 $ terraform state list 簡単な ElastiCache for Redis の検証例 構築したEC2に　SSHアクセスします。（instance_eip は、メモしたOutputsの内容です。） $ ssh -i {SSH キー名} ec2-user@{instance_eip} 下記コマンドで、ElastiCahe に接続します。（primary_endpoint_address は、メモしたOutputsの内容です。） redis-cli はインストール済みです。（module/ec2/user_data.sh 参照） $ ./redis-stable/src/redis-cli -h {primary_endpoint_address} -p 6379 elasticahe-test-redis.xxxxx.ng.0001.apne1.cache.amazonaws.com:6379> 値をsetします。 elasticahe-test-redis.xxxxxx.ng.0001.apne1.cache.amazonaws.com:6379> set key1 "value1" OK elasticahe-test-redis.xxxxxx.ng.0001.apne1.cache.amazonaws.com:6379> get key1 "value1" 管理コンソールから、プライマリノードを選択して、[アクション] > [プライマリをフェイルオーバー]を実行します。 フェイルオーバー中に、 ElastiCaheに接続を試みます。> 接続できない。 $ ./redis-stable/src/redis-cli -h elasticahe-test-redis.xxxxxx.ng.0001.apne1.cache.amazonaws.com -p 6379 フェイルオーバー完了後、 ElastiCaheに再接続して、値が維持されているか確認します。 > 維持されている。 $ ./redis-stable/src/redis-cli -h elasticahe-test-redis.xxxxxx.ng.0001.apne1.cache.amazonaws.com -p 6379 elasticahe-test-redis.xxxxxx.ng.0001.apne1.cache.amazonaws.com:6379> get key1 "value1" 後片付け 下記コマンドで、Terraform で作成したAWS環境を削除します。 $ terraform destroy さいごに 少しでも ElastiCache for Redisの検証に役立てれば幸いです。 参考記事

データベースサービス AWSのデータベースの特徴 通常業務で利用するデータベース（以下DB）サーバーを設計／構築／運用する際には次の作業が必要になる DBサーバー用のハードウェアの要件定義 ハードウェアの調達／DBのインストール 構築時／運用開始後のパッチ適用 DBのバックアップ／リストア設計と実作業 DR対策 AWSのマネージド型DBサービスは上記の作業をAWSに任せることができる ◉マネージド型DBサービスの特徴 最初からDBがインストールされている DBサーバーが動作しているOS／DBソフトウェアのパッチ適用はAWSが行う 自動バックアップが可能 DBのスケールアップ／スケールアウトはAWSの機能を利用できる Amazon Relational Database Service（RDS） マネージド型のリレーショナルDBサービス ACID特性を備えていないといけない 特性 説明 Atomicity（原子性） トランザクション（データ処理）は全て正常に実行 or 無効のどちらか Consistency（一貫性） DBに書き込まれたデータが定義されている全てのルールと制約に従っているか Isolation（独立性） 各トランザクションが独立し、並行処理していること Durability（耐久性） トランザクションの正常完了後、DBに加えられた全ての変更が永続的な状態であること ◎サポートしているエンジン Amazon Aurora Postgre SQL MySQL MariaDB Oracle DataBase Microsoft SQL Server ◉Amazon Aurora Amazon独自のリレーションDBサービス Postgre SQL／MySQLと互換性があり、比較して性能も良い SQL処理を行うDBインスタンスとデータを格納するクラスターボリュームに分かれている クラスターボリュームは3ヶ所のAZに存在する 3つのAZのうちひとつのDBインスタンスはプライマリDBインスタンスと呼ばれ、データの読み取り／書き込みを行う その他2つのDBインスタンスはAuroraレプリカと呼ばれ、データの読み込みを行う 合計で3つのAZの6ヶ所に保存されるため、障害発生時にダウンタイムが発生することがほとんどない ◉RDSの特徴 ◎パッチ適用の管理負荷軽減 曜日／時間帯を時間帯をメンテナンスウィンドウから指定することで、AWSが自動でパッチ適用する ◎バックアップとリストア 標準で1日1回自動バックアップが実施され、DBとトランサクションログを取得 トランザクションログは5分ごとにS3に保存されている DBのバックアップはストレージボリュームのスナップショットを作成し、DBインスタンス全体を取得 最大35日分を保存することができる RDSの復元方法 通常のリストア スナップショットからDBインスタンスを復元 ポイントインタイムリカバリ バックアップのDBとトランザクションが残っている範囲内の特定日時時点にデータを復元 復元すると新しくインスタンスを作成／起動することになるため、アプリケーション側で新しいエンドポイント（ホスト名）に接続するように修正しなければいけない ◉マルチAZ RDSを複数のAZに構築すること Aurora以外のRDSのDBはマルチAZのDBインスタンスを作成すると、マスターDBインスタンスを自動作成して異なるAZにあるDBインスタンスにデータを複製する 耐久性と可用性が向上する ・シングルAZはDBに障害が発生した時、バックアップを利用して復元する必要がある ・マルチAZはスタンバイDBへの切り替えが自動で開始するため、データの損失がほぼない ◉リードレプリカ マスターDBと同じDBを複製し、読み取り専用として構築したもの マルチAZや異なるリージョン間で構築できる マスターDBとの同期処理は非同期で実行される マスターDBとリードレプリカの構成にすることで、読み取り要求と書き込み要求の処理を分離でき、パフォーマンスと耐久性が向上する ◉Aurora Serverless 通常のAuroraと異なり、常にDBインスタンスが起動しているわけではなく、SQLのリクエストを受け取ってからインスタンスが起動する 負荷に応じて、DBインスタンスを自動でスケールする 利用頻度があまり高くないアプリケーション／負荷が一定ではないアプリケーションのデータ格納に適している Amazon DynamoDB マネージド型のNoSQLデータベースサービス 構造化データ以外の半構造データ／非構造データを扱うことができる データの分類 データ構造の種類 詳細 説明 データ／ファイルの例 リレーショナルデータ 構造化データ データ管理する構造を決め、その構造に合わせて格納したデータ 企業の基幹システムなどで管理されているデータ RDB／Excel 非リレーショナルデータ 半構造データ 非構造データを管理できる柔軟性のある構造を用意し、その構造に格納されたデータ システムのログ／IoTデータ／位置情報／SNSデータ／設定ファイルなど LOG／JSON／XML 非リレーショナルデータ 非構造データ 構造が定義されておらず、データの関係をモデルに当てはめることができないデータ テキストファイル（メモ書き）／音声データなど TXT／MPEG ◉キーバリュー型データモデル キーとバリューからデータが構成され、書き込むときはセットで保存される データを呼び出すときは、キーを指定してバリューを取り出す ◉マルチAZ DynamoDBではデータは自動的に3ヶ所のAZに保存される ◉結果整合性モデル 書き込み処理を行なったデータは3ヶ所のAZに分散／保存されるが、書き込み完了に時間差がある タイミングによって、読み込んだデータに最新の情報が反映されていないAZからデータを取得してしまう場合がある Consistent Read（読み取り一貫性）というオプションで書き込みが反映された最新データを読み取ることができる 従来のリレーショナルデータはACID特性の中のConsistency（一貫性）を保証することができる ◉Amazon DynamoDBグローバルテーブル 複数リージョンに配置しているDBテーブルでデータの整合性をとるサービス DynamoDBのテーブル作成時に共通の型（グローバルテーブル）を選択し、複数リージョンに同一テーブルを作成する 全てのテーブルがマスターテーブルのため、どのリージョンのテーブルに対してデータを変更しても、他のリージョンのテーブルに対して同期が行われる ◉Amazon DynamoDBストリーム DynamoDBのテーブルに対して行われたデータ変更（追加／更新／削除）の履歴情報をイベントとして検出し、24時間保持する機能 DynamoDBに負荷をかけずに別途集計／分析処理を行いたい場合 データの変更発生時に迅速にシステム管理者にメール通知したい場合 結果整合性モデルのため、アプリケーション稼働中は常にDynamoDBに負荷がかかる ◉DynamoDBの課金 課金金額は、キャパシティモードと呼ばれる設定によって異なる キャパシティモード 説明 適したユースケース オンデマンド 課金は実行したデータの読み書きに対して発生／事前のパフォーマンスの予測や設定は不要 ワークロードやトラフィックの予測がつかない プロビジョニング済み 事前に１秒あたりの読み書きの回数を予測／Auto Scalingを使用してテーブルのキャパシティを自動調整する DBにアクセスするトラフィックの予測ができる Amazon Redshift BIツールなどを利用した大量のデータの集計／分析に向いているデータウェアハウスサービス ノードと呼ばれているコンピューティングリソースの集合で構成されている リーダーノードが処理を受け付け、コンピュータノードに処理を依頼する ノードの集まりをクラスターという BI（Business Intelligence） 経営上の意思決定に役立てる手法／技術 ◉スナップショット Redshiftは、スナップショットを作成することでバックアップされる（ポイントインタイムバックアップ） 8時間ごと、もしくはノードあたり５GBのデータ変更があったときに自動バックアップ 自動取得したスナップショットの保存期間が過ぎると削除されるため、永続的にバックアップを保存したい場合は手動でスナップショットを取得する ◎クロスリージョンスナップショット スナップショットの格納先は標準でRedshiftのクラスターが配置されているリージョン 別にリージョンにコピーするように設定できる ひとつのリージョンに障害が発生しても、別のリージョンのスナップショットからクラスターを復元できる Amazon ElastiCache インメモリDB（キャッシュ用のDB） 高スループットかつ低レイテンシーな処理が可能 ◉一般的なWebDBアプリケーションの構成イメージ データのアクセス時に常にDBに対するクエリが発生し、負荷がかかる ◉ElastiCacheの構成 DBサーバーの負荷軽減とパフォーマンス向上を実現できる その他のDBサービス ◉Amazon Naptune 高速かつ信頼性の高いフルマネージドなグラフDBサービス ◎グラフDB NoSQLに分類される モノ同士のつながりを表現するネットワーク上のデータ構造 ◎グラフの要素 ノード：データの要素 エッジ：ノード間の関係 プロパティ：ノードとエッジの属性情報 人と人とのつながり（SNS）や乗換案内など、ノード間の関係性の表現や計算に適している ◉Amazon Athena サーバーレスのクエリサービス S3をデータストアとして使用しており、標準SQLを使用してS3内のデータを分析することができる ◉Amazon QuickSight -　フルマネージド型のBIサービス -　DBサービスのRDS／RedshiftやDB以外のS3／Athenaなとど連携してデータをダッシュボードで可視化することができる -　AWS以外の外部DBやファイルデータソースなどの可視化も可能 参考

対象の読者 terraform 超初学者向けの記事となります。当たり前すぎることなのですが、自分はこれにつまずき、半日以上掛かりました。汗 問題 terraform plan を実行したら以下のエラーが発生しました。 Error: No valid credential sources found for AWS Provider. Please see https://terraform.io/docs/providers/aws/index.html for more information on providing credentials for the AWS Provider 原因 エラー文を読むと、どうやらAWSのクレデンシャル情報が見つからないということです。 じゃあ設定すればいいのかなと。 解決策 AWSのアクセスキーとシークレットアクセスキーを設定すれば解決します。 環境変数の設定を行いました。 export AWS_ACCESS_KEY_ID=***（自分のAWSアクセスキー） export AWS_SECRET_ACCESS_KEY=***（自分のAWSシークレットアクセスキー） これで terraform plan が実行できました。

はじめに AWSのプレイスメントグループを勉強するために以下のドキュメントおよび教材を参考にしたので内容をまとめます。 背景 本記事はAWSソリューションアーキテクトプロフェッショナルに合格するために、Udemyの模擬試験を解いて分からなかった部分を勉強してまとめるものです。 試験対策用のため、分からない知識を補足したり試験で問われなさそうなところを省略したりしながらまとめています。 なるべくわかりやすい記載を心がけますが、最終目的は自己学習用であるということをご容赦ください。 プレイスメントグループとは 複数インスタンスを論理的にグループ化して、パフォーマンス性能を向上させたり、耐障害性を高める機能。 クラスタープレイスメントグループ 低いネットワークレイテンシー、高いネットワークスループットが実現できる。 パーティションプレイスメントグループ アプリケーションに関連するハードウェア障害の頻度を軽減できる。 スプレッドプレイスメントグループ 少数の重要なインスタンスが互いに分離して保持される必要があるアプリケーションに推奨される。 プレイスメントグループに適用できるインスタンスタイプ バーストパフォーマンスインスタンス (T2 など) と Mac1 インスタンスを除く現世代のインスタンス。 タイプ 種類 説明 T 汎用 バースト可能 M 汎用 コンピューティング、メモリ、ネットワークの各リソースがバランスよく提供される C コンピューティング最適化 低いコンピューティングあたりの価格率でコスト効率性が高い優れたパフォーマンス R メモリ最適化 メモリ負荷の高いアプリケーション向けに最適化 X メモリ最適化 大規模向け (RAM 1 GiB あたりの価格が最も低い) P 高速コンピューティング 汎用 GPU コンピューティングアプリケーション用に設計 G 高速コンピューティング グラフィック集約型アプリケーション用に最適化 F 高速コンピューティング FPGA(集積回路の一種)によるカスタマイズ可能なハードウェアアクセラレーション I ストレージ最適化 低レイテンシー、極めて高いランダム I/O パフォーマンス、優れたシーケンシャルリードスループットのために最適化 D ストレージ最適化 ディスクスループットパフォーマンスあたりの価格が EC2 で最小 H ストレージ最適化 高ディスクスループット、およびバランスの取れたコンピューティングとメモリを実現 汎用 : バランスの取れたコンピューティング、メモリ、ネットワークのリソースを提供 コンピューティング最適化 : 高パフォーマンスプロセッサの恩恵を受けるアプリケーションに最適 メモリ最適化 : メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現 高速コンピューティング : 浮動小数点計算、グラフィックス処理、データパターン照合を効率的に実行 ストレージ最適化 : 数万 IOPS もの低レイテンシーなランダム I/O オペレーションに最適化 設定方法 先にプレイスメントグループを構成した上で、その中でインスタンスタイプとインスタンス数を決定する。

記事作成にあたって 最近DynamoDBを触るようになってRDBと設計思想が違うから、いまいち操作しにくい。それでも騙し騙し実装をしていたが、あれ？これってプライマリーキー検索以外の場合ってできないの？LSIやGSIってのを定義すれば検索できるけど、なんで検索キーを事前に登録しておかないといけないの？って感じたので、一旦立ち止まって、整理することにしました。 プライマリーキー DynamoDBではプライマリーキーの指定方法は2通り。 1. パーティションキー 2. パーティションキー＋ソートキー パーティションキーって何？ DynamoDBは分散型DB。RDBのようにデータを一箇所に集約するのではなく、複数の場所にデータを格納する。そのため、どの場所にデータを格納するのかを決める必要がある。で、配置場所を決定するのにパーティションキーを使う。RDBを触り続けた人にはなんだこれってなるかも心ないですけど、分散時に利用するキーなのねってくらいの理解でいいと思います。 セカンダリインデックス インデックスって聞くと、データ検索を効率的に検索するための目次のことね。って理解だと痛い目見ます。実際、この理解で結構苦しめられました。。。 RDBだとWhere句に検索条件を指定すれば、欲しいデータを絞りこむ事ができた。だけどDynamoDBだと、予め検索キーをしておかないと絞り込み検索できないのです。何もしないと、プライマリー検索しかできない。なので、セカンダリインデックスを作っておく必要があります。セカンダリインデックスって聞くと難しく聞こえるけど、イメージは新しいTBLを作ってそこから検索してね。って感じ。 LSI(ローカルセカンダリインデックス) ローカルセカンダリインデックスは公式の見解では下記の通り。早い話がパーティションキーはそのままで、ソートキーで新しく検索するイメージ。 ローカルセカンダリインデックスは特定のパーティションキー値の代替ソートキーを維持します。またローカルセカンダリインデックスには、ベーステーブルの一部またはすべての属性のコピーが含まれます。テーブルを作成する際に、ローカルセカンダリインデックスに射影する属性を指定します。ローカルセカンダリインデックスのデータは、ベーステーブルと同じパーティションキーと、異なるソートキーで構成されます。これにより、この異なるディメンションにわたってデータ項目に効率的にアクセスできます。クエリまたはスキャンの柔軟性を向上させるために、テーブルごとに最大 5 つのローカルセカンダリインデックスを作成できます。 LSIの具体例 ThreadテーブルからLastPostIndexを作って検索する。その際に、元々パーティションキーであったForumNameカラムはそのままで、ソートキーのLastPostDateTimeは新たに定義しなおす。 GSI(グローバルセカンダリインデックス) グローバルセカンダリインデックスは公式の見解では下記の通り。早い話が、パーティションキーもソートキーも新たに定義し直して、新規のテーブルを作るイメージ。 すべてのグローバルセカンダリインデックスには、パーティションキーが必要で、オプションのソートキーを指定できます。インデックスキースキーマは、テーブルスキーマとは異なるものにすることができます。シンプルなプライマリキー (パーティションキー) を持つテーブルを作成し、複合プライマリキー (パーティションキーおよびソートキー) を使用してグローバルセカンダリインデックスを作成できます。またはその逆もあります。インデックスキー属性は、ベーステーブルからの任意の最上位 String、Number、または Binary 属性で構成できます。その他のスカラー型、ドキュメント型、およびセット型は許可されません。 GSIの具体例 GameScoresテーブルからGameTitleIndexテーブルを作成する。その際にパーティションキーもソートキーも新しく作る必要がある。

はじめに お久しぶりです、なじむです。 最近 AWS のアップデートをそこそこ真面目に追うようになったので、AWS Japan さんがまとめている週刊AWSで確認した内容を自分のメモ用に残していこうと思います（目標は毎週更新…） 間違っている内容があるかもしれないので、見つけたらコメント等いただけると嬉しいです。 今回は7/19週のアップデートです。 7/19(月) Amazon EBS io2 Block Express Volumeの一般利用開始(GA)が発表されました AWS 初の SAN (Storage Area Network) である io2 Block Express ボリュームが利用可能になりました。io2 Block Express の登場前まではオンプレの SAN と接続するしかありませんでしたが、これにより AWS だけで Oracle、SAP HANA、Microsoft SQL Server および SAS Analytics 等、I/O 負荷の高いミッションクリティカルなデプロイに最適な構成を組めるようになりました。io2 Block Express ボリュームは以下のような特徴を持ちます。 最大 256,000 IOPS 4000 MB/秒のスループット 64 TiB のストレージ容量 gp2 タイプや Block Express でない io2 タイプと比較すると以下のような性能差です。 (出典) AWS News ブログより 作成方法は通常のEBSの作成方法と同じですが、Block Express か非 Block Express かを選択する項目は特になく、Block Express に対応したインスタンスタイプ（執筆時点では R5b のみ）を使用していれば自動的に Block Express となり、IOPS を 256,000 に設定できます。 r5b.large のインスタンスタイプの場合 t2.large のインスタンスタイプの場合 大阪リージョンでは R5b インスタンスに対応していないため、io2 Block Express にも対応していません。 日本リージョン対応状況 東京：対応 大阪：未対応 7/20(火) Amazon RDS Cross-Region Automated Backupが利用可能なリージョンが拡大 Oracle や MySQL と言った RDBMS のマネージドサービスである RDS で、リージョンを跨いで自動的にバックアップを取得できる Cross-Region Automated Backup の対象リージョンが追加されました。身近なところだと、これまでは東京→大阪へのバックアップは対応していましたが、その逆の大阪→東京は対応していませんでした。今回のアップデートで、大阪→東京へのクロスリージョンバックアップもできるようになりました。 実際の画面は以下です。 大阪リージョンからは東京リージョンへのバックアップしか対応していないので、日本国外へのクロスリージョンバックアップを検討している方はご注意ください。 東京リージョン 大阪リージョン アップデートの内容だと、以下のバージョンで使用できると記載があったのですが、SQL Server は画面上の設定項目を確認できませんでした。見るところが悪かった…？ Oracle　　：12.1 (12.1.0.2.v10 から) 以降 PostgreSQL：9.6 以降 SQL Server：SQL Server 2014 以降 日本リージョン内でDRが組めるようになったのは大きいですね。使う方も増えてきそうです。 日本リージョン対応状況 東京：対応 大阪：対応 AWS CodeBuildが大阪リージョンでもご利用頂けるようになりました 継続的インテグレーション (CI) のマネージドサービスである CodeBuild が大阪リージョンで使用できるようになりました。 仕様を最初に決めて一度に大きなリリースをするウォーターフォール型と異なり、小さなリリースを何度も繰り返すアジャイル開発の現場では、開発 > ビルド > テスト > リリースを早いサイクルで実施する必要があります。開発は手動で実施する必要がありますが、テスト、リリースを毎回手動で実施するのは大変です。それを自動化しようというのがCI/CDという考え方です。 (出典) DevOps on AWS: Deep Dive on Continuous Delivery and the AWS Developer Tools AWSではCodeシリーズがそれに該当し、以下のようなマッピングです。 実際の画面は以下です。大阪リージョンで使用できていますね。ただ、CodePipeline だけ大阪リージョンで未対応のためご注意ください。 日本リージョン対応状況 東京：対応 大阪：対応 Amazon RDS for SQL Serverで新たなマイナーバージョンが利用可能に Oracle や MySQL と言った RDBMS のマネージドサービスである RDS で、SQL Server の以下マイナーバージョンが使用できるようになりました。 詳細なアップデートの内容は確認していないので、Microsoft 社の公式ページを参照ください。 SQL Server 2017 14.00.3381.3.v1 SQL Server 2016 13.00.5882.1.v1 実際の画面は以下です。どのエディションでも使えるようになっていました。 日本リージョン対応状況 東京：対応 大阪：対応 Amazon EKSとEKS DistroがKubernetes version 1.21をサポート Kubernetes のマネージドサービスである EKS と、EKS で使用している Kubernetes の OSS である EKS Distro で Kubernetes の 1.21 が使用できるようになりました。 Kubernets 1.21 では Cronjobs の正式版が利用可能になっているので、待っていた方も多いのではないでしょうか。詳細な更新内容は Kubernetes 公式を参照ください。 実際の画面は以下です。1.21 が使えるようになっていましたが、デフォルトはまだ 1.20 でした。 Kubernetes を使用する上では EOSL が気になるところですが、Amazon EKS Kubernetes release calendarを確認すると 1.21 は 2022年9月までのようです。 ※日本語ページだと執筆時点では 1.20 までしか記載がなかったので英語ページを参照ください。 日本リージョン対応状況 東京：対応 大阪：対応 7/21(水) Amazon AthenaのPower BI用データソースコネクタを発表 Microsoft 社が公開している BI (Business Intelligence) ツールのクライアントアプリである Microsoft Power BI Desktop でデータソースに Amazon Athena が選択できるようになりました。これにより、Microsoft Power BI Desktop で Athena のデータを使用して、Power BI のダッシュボードやクエリが行えるようになりました。 ※BI ツール：企業に蓄積された大量のデータを集めて分析し、迅速な意思決定を助けるのためのツール。経営管理や売上のシミュレーションなどに活用できる。 これが出る前までは、データソースに ODBC を選択して Athena に接続していたようです。 (参考) Power BI DesktopからAmazon AthenaにODBC接続してみた 以下のチュートリアルがとても参考になったので気になる方は試してみてください。 (参考) Creating dashboards quickly on Microsoft Power BI using Amazon Athena 実際の画面は以下です。テスト用に構築した EC2 から Microsoft Power BI Desktop を介して Athena に接続ができました。 Microsoft Power BI Desktop から Athena への接続。ただ、見つかったのは Beta 版…？古い AMI を使用してしまったかもしれません。 Microsoft Power BI Desktop でデータの集計 大阪リージョンでは Athena 自体が未対応のため、本機能も対応していません。 日本リージョン対応状況 東京：対応 大阪：未対応 7/22(木) Amazon VPCでEC2インスタンスに対してIPプレフィックスを割り当てることが可能に ※具体的な動作を検証していないので推測込みです※ EC2 インスタンスの ENI に IPv4、IPv6 のプレフィックスを割り当てられるようになりました。これにより EKS や ECS、Docker on EC2 等、インスタンスに複数の IP アドレスを必要とするコンテナアプリケーションやネットワークアプリケーションのスケールや管理の簡素化が可能になりました。 なるほど、分からん。ということで、EKSの場合で推測してみようと思うのですが、EKS のデータプレーンに m5.large の EC2 を使用している場合、付与できる IP アドレスは最大 30 個（アタッチできる ENI：3 つ、 ENI あたりの IP 上限：10個）です。つまり、インスタンスあたりの稼働できるコンテナ数も 30 個までとなります。 (参考) https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI 本機能を使用することで何百、何千の IP を付与できるようになるため、インスタンスあたりで稼働できるコンテナ数も何百、何千になるのでは、と思いました。ただ、実際の画面で軽く見た感じだとそうでもないのかなと感じ、ここは実際に環境を構築しないと分かりませんでした。。 プレフィックスはEC2インスタンスの作成時に指定します。採番方法は以下2通りあります。 Automatic assignment — AWS が自動的にプレフィックスを割り当ててくれます。 Manual Assignment — 自分で xxx.xxx.xxx.xxx/28 のプレフィックスを指定します。 実際の画面だと以下です。 インスタンスタイプにより設定できるものとできないものがあり、例えば t2 シリーズでは設定できず、m5 シリーズでは設定できました。また、m5.large, m5.xlarge だと Automativally assign で付与できるプレフィックスは 1 つでした。この辺の仕様はどのドキュメントを見れば分かるのだろう… Automativally assign でプレフィックスを付与すると、xxx.xxx.xxx.xxx/28 のプレフィックスが付与されるので、16個のIPアドレスが付与できるようになるものと思います。 設定画面 設定値の確認 詳細は内容は Assigning prefixes to Amazon EC2 network interfaces を参照ください。 ドキュメント上だと "すべてのパブリックリージョンとAWS GovCloud (米国) でご利用いただけます" と記載があったのですが、大阪リージョンではプレフィックスを設定することができませんでした。大阪リージョンはパブリックリージョンではない…？ 日本リージョン対応状況 東京：対応 大阪：未対応 AWS Serverless Application Model Pipelines(AWS SAM Pipelines)のパブリックプレビューを開始 SAM で CI/CD パイプラインの機能がパブリックプレビューとして公開になったなったようです。 このアップデート、私が SAM をよく分からないために説明できないのですが（調べるのに力尽きた…）、Classmethod 社のブログを参考にして頂くとイメージが湧くかなと思いました。詳しくは以下記事を参照ください。 (参考) パブリックプレビューのAWS SAM パイプライン機能を試してみた 日本リージョン対応状況 東京：対応 大阪：対応 ※CodePipeline を使用する場合は未対応かも。Jenkins 等を使用する場合は大丈夫そう。多分。 7/23(金) AWS Glue DataBrewが自動生成するデータクオリティに関する統計処理を指定可能に コードを書かずに、GUI でデータクレンジングや正規化と言ったデータの前処理を行うことができる（個人的にはめっちゃエクセルに見える）サービスである Glue DataBrew で、プロファイルジョブを実行する際に重複値、相関値、異常値等、どのデータ品質の統計を生成するか指定できるようになりました。 Glue DataBrew のプロファイルジョブは前処理を行うデータの包括的なプロファイル情報を作成するための機能です。これまではデフォルトで重複値、相関値、異常値等、全ての項目の統計を生成していましたが、今回のアップデートにより、任意の項目を選択できるようになりました。おそらく、統計の項目を減らすと使用するコンピュータリソースも減るので、ジョブの実行時間が短縮され、それに係る料金も減るものと思います。 実際の画面では以下です。今回のデータセットは、AWS がサンプルとして用意している「有名なチェスゲームの動き」を使用しています。 すべての統計を無効にしたら、だいぶ簡素になってしまいました… 設定画面 すべての統計を有効にした場合の結果画面 すべての統計を無効にした場合の結果画面 大阪リージョンでは Glue DataBrew 自体が未対応のため、本機能も対応していません。 日本リージョン対応状況 東京：対応 大阪：未対応 ※Glue DataBrew 自体が未対応 Glue DataBrew は真剣に触ったことがないので、いつか AWS Glue DataBrewハンズオン をやろうということで個人的なメモ。 AWS Glue DataBrewでプリパレーションが完了したデータをJDBCを介して直接書き込み可能に 次も同じく Glue DataBrew のアップデートです。 データのフィルターやグループ化を定義したレシピを実行するジョブで、分析結果の出力先に JDBC に対応した DB (MySQL, Oracle, SQL Server 等) や DWH (Redshift 等) に直接出力できるようになりました。 実際の画面は以下です。今回は DB を用意していないので実際の動作は確認していません。 大阪リージョンでは Glue DataBrew 自体が未対応のため、本機能も対応していません。 日本リージョン対応状況 東京：対応 大阪：未対応 感想 調べたことで何となく分かった気になりましたが、思った以上に日記帳になりました。アップデートを真面目に見ようとすると分からないことが多いということも分かりました…特に普段使わないサービスは（そして力尽きた…） ただ、自分のためにも、このブログ投稿を通じて徐々に知識を増やしていこうと思っているので、毎週継続してやっていこうと思います。 間違っていたらその時はその時で…その際はご指摘ください。理解が間違っていたことが分かったという大きな進歩になりますので。

はじめに この度、AWS Certified Solutions Architect - Associate 試験(SAAとかソリューションアーキテクトとか言われるやつ)を受験して合格したのでこれまでの総括をしようと思います。 AWS未経験とかの合格記とかはちらほらありますが、IT業界の業務未経験でかつインフラの知識もほぼない人間の合格記はあんまりないと思うのでこれから受験する方の尺度になれば幸いです。 なお、試験問題の内容については規約で口外できないのであしからず。 過去のアウトプットは過去記事から参照していただけると嬉しいです。 私のスペック 元国公立志望系私文卒の29歳でフリーター IT系の資格はITパスポートくらい ちょっとWebアプリを作ったことがある(よかったらQiita過去記事から参照していただけるとありがたいです) 算数は小2で捨ててしまったクチでセンター試験では数IA2B合わせて50点しか取れないくらいに数字が苦手 辿った経歴は文系だが、見た目とかアプローチとか考え方は理系とよく言われる でも、最後は感覚で片付けるタイプ 集中力に欠けるので完全座学は1日に長くて4時間が限界 要はITの世界の人間から見れば雪山で裸でタップダンス踊っているような人間でもなんとかなったというのが今回のお話です。 なんで受けたのか 就職活動がさっぱりうまく行かないから それに付随してとある企業様の面接の担当者様に「資格もないの……はぁ……(クソデカため息)」と言われてしまったから 自分でもDjangoとReactでアプリ作ったり、そもそも作ったものをデプロイするときに困ったりするのでなにか1つでも既存のプラットフォームの知識をつけたほうがいいと思ったから 昨年 Masuyamaさんと一緒にDjangoでWebアプリ開発をする機会があり、そのときにMasuyamaさんや他の参加者様がデプロイにAWSを使っていてすごいなと興味を持ったから 上記の経緯を踏まえてTwitterのCADの仕事しているフォロワーさんが受験すると聞いて、じゃあ自分もやるか……と思ったから それ以前にAWSはやたらよく聞くので試しにJAWS DAYS2021の初心者セッションに参加したら結構楽しかったから 使った教材 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） AWS サービス別資料(通称Black Beltとか黒帯とか) AWSのオンラインセミナー(個人的には結構重要) 色々調べた結果、これ以外では黒本と呼ばれる教材くらいが選択肢に入るくらいでいいと思います。 本試験受けた身としては模擬試験は完全に当てにならないので、模試として受けるよりはそれをとっかかりにサービスへの理解をより自分で深めていくという方針の方が合格する確率上がりますし、資格を取る意味的にも良いかと思います。 ちなみにホワイトペーパーは英語版で読まないといけないので私は使ってません、ただ本試験は問題文や選択肢の日本語がだいぶ怪しく英語ができる人は英語で受験する方が楽ってレベルなのでそれに慣れる意味では使う意義はあると思います。 以下個別に。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） 下調べしてこれがいいというのをちらほらと聞き、Masuyamaさんも当時おすすめしていた気がしたのでこれを買ってやってみました。 良かった点は 完全0ベースの私でもとりあえずこれさえやってるうちに道しるべにはなるだろうと思った通り、割とロードマップにするには良い教材だったところ ハンズオンが必ずあること 模擬試験(個人的には本試験の2段落ちくらいの難易度)が2つあること 悪かった点は 0べースの場合は自分でわからない用語や理解しきれなかった部分は調べないと力にはならないところ 試験範囲が完全に網羅されているわけではない(この講座よりもやや踏み込んだ内容であったり、問題の問われ方を本試験ではされる)のでこれだけでOKとはなりにくいだろうというところ 解説やスライドが間違っている(フォローするとおそらくAWSの更新速度の速さに教材の更新が追いついていないところ)ところ 講師に質問してもすぐ返ってこない上に、わざわざこんなこと聞くなよ！ みたいな感じでリンクだけ貼られて返信されたりするので気になる人は気になるところ(私は自分でさっさとググるので無問題) 総評するとAWSを業務で全然触ってない方はとりあえず買っても問題ないと感じます。 Udemyなので30日は返金できますので、やってみてなんかちゃうわってなったら返金してもいいですし。 書籍だと黒本と呼ばれるのを使われている方が多いですが、私はお金ないの、書籍ではAWSの更新スピードに対応できてないだろうという判断、書籍を使った勉強が致命的に苦手という理由で買いませんでした。 もちろん黒本自体は見る限りは実績ある教材みたいなので手にとって確認されることをおすすめします。 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） 多分、模擬試験足らないなという判断で受験1ヶ月前に買いました。 先述の講座付属の模擬試験が基本レベルだとすると、こちらは同じレベルの問題が1回分とやや応用かつ、網羅的な問題集という感じです。 ちなみに基本1回以外の5回は試験範囲的にはそれぞれやや偏りがあるので、全部やることで網羅的に自分のステータスがわかるという感じです。 良かった点は 問題数が多く、かつ基本レベルから踏み込んだ聞かれ方やあれ講義でそんなこと言ってたか？ みたいな細かいところまで聞かれるところ どの分野でどれくらい間違えてるかなどをグラフ化してくれるところ 見直しは自分でチェック入れたところ、未回答、間違えたところ、正解したところとフィルタリングできるところ 悪かった点は 本試験リスペクトなのか問題文や選択肢が怪しい上に、え？ その聞き方だと解答も2つあるように感じるけど？ みたいな問題がいくつかある(解説みてまあそういう解釈もできなくはないかなぁ……と思うレベル) 解説がコピペくさいところと正直あんまり当てにならないので、自分でBlack BeltやClassMethodさんのブログ見たほうが理解は深まりそうなところ 講義で出てない用語やサービスをいきなり問題で出されるのでええ……となるところ(個人の感想です) ちなみに模擬試験と書いてあるのでみんな誤解しがち(レビューでも散見される)ですが、あくまで AWS試験は多数の問題がプールされており、一度の試験では出ない問題が多数ありますが、参考書にあるような問題は簡易な問題のみを取り扱っており、実際の試験の方が難しいものが頻出します。本講座では難易度の高いレアな問題を多数取り扱って試験慣れしてもらうことを目的に構成しています。 ※本模擬試験は多様で難易度が高い問題になれてもらうことで、合格する可能性を高めることを目的としているため、正答率が70％未満であっても、本試験に合格することができる方も多いです。正答率が本番試験の合格レベルを決めるものではない点をご注意ください。 というところが主眼であり、実際に本試験を受験した身からするとこの教材は解説を見て手に余るようなところを探して、Black Belt他の情報リソースを自分で探して理解を深めるためのツールに過ぎないのでご注意を。 個人的にはこの試験の1段上くらいが本試験の難易度だと思いました。 AWS サービス別資料(通称Black Beltとか黒帯とか) AWS サービス別資料 個人的に今回のMVPその1。 色々な方が勉強に使ってるのも頷けるくらいに良い教材です。 何故かいうとAWS SAA試験では(多分AWSの試験に共通することだと思いますが) サービス自体の理解 そのサービスと他のサービスとの連携の理解 さらにそれらの実際のユースケースの理解 これらを深めないと勉強したことが中々頭に入ってこないと思うからです(個人の感想)。 実際に上述の教材の模擬試験でもこの3点を意識した問題の問われ方をされていました。 で、この3点を各サービスごとに1時間程度で動画でまとめてくれていてしかもスライドをPDFでも用意してくれている神みたいな教材がこれなんです。 私みたいな業務経験のない人間はユースケースについてはかなり不利になるので、それをほぼ必ず紹介してくれているこの教材はとてもいいと思いました。 なお、必須というわけではなく業務経験があったりする(非AWSでもIT系の知識があるとかでも可)人は効率悪いから使わなかったと、あるRTA記事で拝見しました。 AWS主催のオンラインセミナー 今回のMVPその2。 毎月どころか下手したら毎週AWSはオンラインセミナーをやっていて、現役のAWSエンジニアさんたちがいろんなプレゼンをしてくれています。 特に最新のAWSサービスのユースケースや新技術、あとはベストプラクティスなんかを語ってくれることが多いのでやはり業務経験ない私にはありがたかったです。 ちなみに言ってることは半分くらいギリギリ理解できるレベルでしたが、それでもだいぶ助けにはなりました。 私が受けたのはAWS Builders Online SeriesとJAWS-DAYS 2021(初心者向けセッションです)。 面白かったのはAWSで利用されるDBサービスのあれこれを利用用途に分類して小一時間でさっと語ってくれたセクションとAWSでのデータ分析のセクションでした。 ハンズオンもあったりするのでAWS SAA取ろうと思うなら受けて損はないと思います。 タイミングによってセッションとしてAWS試験対策をやってくれたりもするので気になる方はチェックしてみると良いかと。 Q&A 勉強期間は？ A. 4月半ば～7/30(試験日)です。 ただしこれは私がド素人かつ座学ができないタイプの人間で、しかもながらでやるタイプかつエンジンもスロースターターという特性だからという話で、おそらく実務でAWSを使ってる方なら1ヶ月半、AWS未経験でもインフラ経験や知識、ノウハウがある方なら2ヶ月、慎重になって3ヶ月くらいだと思います(もちろん、個人差あり) どんなことやってたの？ A. 4月～6月でUdemyの講義、6月～試験日前日までひたすら模擬試験とBlack Beltでした。 前述の通り私は集中して10時間も勉強することができないタイプなので変わりにほぼ毎日4時間位やってました、大体仕事or家事して勉強して寝る以外のことをこの期間ほぼやってません。 講義の方は当然初見では全く話も入ってこなくて、何言ってるかもわからないので当然つまらないのでBGMみたいな感じで聞いてました。 途中からなんとなくやり方が見えてきたので、講義の後半の方で 初見はBGMとして聞いて何をやるのかとか興味を持てそうなところをなんとなくPUしていく 2回目はちゃんと聞く。 付属のハンズオンをやる 3回目を聞いて、わからない用語や理解しきれない部分は自分で調べてアウトプットする というリズムを作れるようになってからはこれをセクションごとにやっていました。 1セクション1時間～4時間くらい動画だけであるので作業量はその3倍以上とかになってます。 これは人それぞれの練度によって変わってくるので当然圧縮することも可能でしょう、1.5倍速で聞くことを勧めている方もいます。 ハンズオンはできる限り必ずやりましょう、手を動かさないと覚えません。 あと、個人的にはハンズオンはセクション、あるいは関連セクションでまとめてやることを強くおすすめします。 というのもAWSのサービスは作ったリソースをそのまま放置しておくと課金対象になる罠が至るところにあるので、逐一ハンズオンごとに削除しないといけないのですが、ハンズオンはリソースを削除していない前提で始まるので当然もう一度作り直すことになります。 VPCとかEC2くらいだったらまだいいのですが、ElastiCacheとかRedshift、RDS等の高額のサービスでうっかり削除を忘れてしまうと高額の費用を請求されるなんてことがあるのでくれぐれも気をつけてください(受講生の中にはElastiCacheを放置してしまい、17万請求された方がいらっしゃいました)。 模擬試験とBlack Beltに関しては 1周目を普通に解いて、解説を全部読んで何間違えてなぜ間違えたかをアウトプットする 弱いと感じたサービスはBlack Beltを確認する 2周目は問題の選択肢を根拠付けて潰すようにして説いていく 根拠が曖昧だったりしたサービスについてもう一度Black Beltを見て、総まとめとしてアウトプットする 3周目は試験前に総決算として解く という感じでやってました。 この段階のが楽しかったですね。 Black BeltでおすすめなのはSQSのBlack Beltです。 これを見ればSAAレベルのSQS知識はもらったも同然レベルで、正直Udemyの講義よりも質はいいのでぜひご覧になっていただければ。 下に各模擬試験の私の得点推移を載せておきますので、後述の実際の試験の点数と合わせて合格可能性の判断基準にして頂ければと思います。 ホワイトペーパーとWell-Architected Frameworkは読んだ？ A. 読んでないです。 ホワイトペーパーについては前述の通りです。 Well-Architected FrameworkはUdemyの講座2周したくらいで、オリジンは読んでません。 というのもあれはAWSを実際に利用している人達向けのマニュアルみたいなものなので勉強のコスト効率としては著しく悪いです。 ただし、Well-Architected Frameworkと11のベストプラクティスに基づいてAWSサービスは展開されているので、AWSを効率よく理解するのに適した概念であるのでどんなものであるかということと、何に注目して勉強を進めていけばいいかということを把握するためにも大切なものではあります。 ぶっちゃけ試験に出やすい範囲とかサービスってあるの？ A. 極論、試験範囲のサービス全て出ると思って勉強したほうがいいです。 理由は2つあって1つはこれまでもちらほらと書いたとおり、AWSはサービス間の連携を理解するのが肝であり、実運用でもそれが当たり前だからです。 このサービスはどういうサービスで、なんのためにあって、だからこんなサービスと連携して、こんなユースケースを作っている……と理解できればできるほど合格の可能性が高まると個人的には思います。 2つ目はAWSの試験はなんでも1000問以上プールされていて試験によってそこからランダムで65問出題されるので、正直Udemyの模擬試験を全部やってもせいぜい700問弱なので30%強の確率で自分でカバーしきれない範囲が出てきます。 そういうこともあってサービスはユースケースと連携で覚える必要があると思いました。 試験範囲全部とか面倒くさい A. わかります。 なんでもSAA及びその上位資格であるSAPはAWS試験の中でももっとも広範な試験範囲らしく、実際かなり膨大な範囲です。 正直私も全部のサービスどころか1つとして完全に理解しきれたサービスはないくらいには広いです。 なので最終的に私は以下のような区分でサービスを分類していました、よかったら参考にしてください。 AWSの基本的なアーキテクチャを作成するためのサービス EC2 VPC S3 Route53 AutoScaling ELB CloudWatch CloudFront(コンテンツ配信を行うようなサービスの場合) 特にサーバレスなアプリケーションを構成する場合のサービス Lambda SQS SNS APIGateway ElastiCache DynamoDB(非ステートレスであれば) Step function (分散アーキテクチャの疎結合を助ける、特にオンプレミスのワークロードとの連携もできる) データ分析ワークロード Lambda SQS S3 Redshift Athena Glue EMR Kinesis LakeFormation アプリケーションやワークロードの自動化、テンプレート OpsWorks Cloud Formation Step function(分散アーキテクチャやマイクロサービスでの疎結合化を図るが、本質はワークロードの設定や管理の自動化。タスクで構成されるワークフローを簡単に作成できる) SWF(Step FunctionのEC2インスタンスを使う版。) コンテナサービスによるマイクロアーキテクチャ Elastic Beanstalk(ECS、EKS、ECRと連携して自動化) ECS EKS リポジトリ管理からデプロイまでのワークロード CodeCommit(リポジトリの管理、つまりソースコード管理) CodeBuild(コードのビルド及びテスト担当) CodeDeploy(ビルドに成功したモジュールのデプロイ担当) CodePipeline(上記の3工程をCI/CD化するサービス) 公式の模擬試験は受けた？ A. 受けてません。 2000円(AWS資格を有していると特典で無料)もかかるのに難易度は本番より低く、問題数20問強くらいしかないみたいなので…… ただ、日本語の酷さ(Google翻訳らしい)は味わえるみたいなので本試験の日本語が不安な方は受けてみるのもいいと思います。 結果 以下の通りのスコアとスコアパフォーマンスで合格しました。 正答率は51/65なので14問程度ミスっているということになります。 どこ間違えてるかは確認する術はありません。 可もなく不可もなくという感じだと思います、試験本番の手応え的には結構ぎりぎりかな……と思っていました。 最後に 受けてみて結構良かったと思っています、なんだかんだAWSはもう知っていることが前提みたいな感じで接せられることが多いので今後は(多少は)私も自信を持って話に参加できるようになるのかなと。 ともかく、早く就職して実務経験積みたいですね……資格も3年しか持たないのでDevOpsとか横の資格も取りたいですしSAPもチャンスがあれば挑戦したいですし(難易度は実務経験ないとしんどそう)。 勉強していてAWSインフラのエンジニアにも興味が持ててきたのでもしこの記事読まれた方で私に興味を持っていただけたらお声をかけていただけると嬉しいです。

はじめに ポートフォリオとして制作したアプリケーションのポイントを投稿させていただきます。 ポートフォリオURL：https://task-time.net (まだGoogleCloudPlatformの審査中のため、ログインページから先は進めません。) GitHub：https://github.com/Nakamura9310/TaskTime アプリケーションのコンセプト 「①全タスクをメモし②所要時間を見積もり③全てカレンダーに入れる」ことで 多忙な時に真価を発揮する、タイムマネジメントアプリ 前職時に本当に多忙な毎日を送る中で、タイムマネジメントの重要性を知りました。 タスクをメモするだけではダメです。 どのタスクに何時間かける予定か、カレンダーに落とし込むことができていれば、 タイムマネジメントができているといえます。 ①〜③ができていると →新しいタスクが発生した時に、いつ実行可能なのか瞬時に判断できる。 ①〜③ができていないと… ▲下手にタスクを受け、期限内に終わらない量のタスクを抱えることになる。 →一人でタスクを抱え込み、チーム内で自分のタスクが過多となる。 ▲期限延長を依頼するべきか or 周囲を頼るべきなのか等を適切に早く判断できない。 →最悪期限を守れなかった場合は社内外に迷惑をかける。 理想 (今を月曜の午前中とすると) 先輩「悪いけどこの見積やっといてもらえる？多分30分くらいで終わるからさ。」 自分「今タスクが↓こんな感じの状況なので最速でも取りかかれるのが水曜の13時からですね。それでもOKですか？」 先輩「あ〜じゃあ他の人に任せるわ。」 自分「了解です〜。」(勝った…！) アプリの概要 以下の機能を備えています。 1.SpringSecurity と GoogleOAuthを用いたログイン機能があります。 2.シンプルなタスクのCRUD処理ができます。 3.各タスクに設定した見積時間から、今週の各日のタスク山積状況が分かります。 4.GoogleCalendarAPIを用いてタスク情報からGoogleCalendarに予定を追加できます。 環境・使用技術 macOS BigSur Java (AdoptOpenJDK 11.0.10) SpringBoot 2.5.2 MySQL 14.14 MyBatis 2.2.0 Thymeleaf 2.5.4 SpringSecurity(Spring Boot Starter Security » 2.5.4) Google OAuth 2.0 GoogleCalendar API HTML / CSS / MDBootstrap JavaScript(画面の一部のみ) AWS(VPC/EC2/RDS/Route53/ALB/ACM) 画面イメージ・使い方 ログインページ Topページ タスク追加デモ (タスクの予定日が昨日以前の場合は背景が薄赤色になります。) (当日は赤字、翌日は太字になります。) タスクは「予定日順」と「優先度順」で並び替えができます。 Googleカレンダーに予定としてタスクを追加できます。 タスク追加のコツ ・見積時間や予定日は仮でもOKなので入れてください。 ・「週間タスク状況」欄には今週のタスク山積状況が表示されます。 ・こちらを見ながら予定日を決めていってください。 ・ほとんど予定日が確定したら、Googleカレンダーに予定として追加してください。 タスクが完了したら緑色の「✓」ボタンを押してください。 (Doneページにタスクが移動します。) Todayページ Doneページ 最も苦労したポイント Googleカレンダーに予定を追加する機能を実装する際、 「Java×SpringBootでログイン機能中のユーザーのカレンダーに予定を追加する」方法については公式ドキュメントに記載がなく、また解説している記事等も無かったため、 GoogleAPIの公式Javadocから必要な情報を読み解いた点が最も苦労しました。 注意点 動作確認はGoogleChromeのみで行っています。 連動できるGoogleカレンダーは、タイムゾーンAsia/Tokyoのプライマリカレンダーのみです。 課題・改善点 タスクとGoogleカレンダーのイベントは、追加時以外リンクしていない状況なので、編集/削除時にも連動するようにしたい。 FullCalendar(JavaScriptのライブラリ)などを利用して、Googleカレンダーの表示を綺麗にしたい。 以上です！ お読みいただきありがとうございましたm(_ _)m