DynamoDB の Docker イメージが公式から提供されていたので、このイメージを使用してローカルに DynamoDB をデプロイしてみます。さらに、ローカルに構築した DynamoDB にデータをインサートしてテーブルの中身を確認するところまでやってみたいと思います。 Docker で DynamoDB を構築 docker-compose.yamlを用意して、次の内容をファイルにコピーして保存します。 docker-compose.yaml version: '3.8' services: dynamodb-local: command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data" image: "amazon/dynamodb-local:latest" container_name: dynamodb-local ports: - "8000:8000" volumes: - "./docker/dynamodb:/home/dynamodblocal/data" working_dir: /home/dynamodblocal コンテナを立ち上げます。 docker-compose up -d DynamoDB Local の構築は以上で終わりです。さすが Docker といった感じでとても簡単です。 サンプル: データをインサートする ローカルに DynamoDB が構築できたら、実際にデータを登録してみます。まずは、テーブルを作成します。 aws dynamodb create-table \ --region ap-northeast-1 \ --endpoint-url http://localhost:8000 \ --table-name animals \ --key-schema AttributeName=id,KeyType=HASH \ --attribute-definitions AttributeName=id,AttributeType=S \ --billing-mode PAY_PER_REQUEST テーブルが作成できたか、list-tables コマンドを使って確認します。 $ aws dynamodb list-tables --endpoint-url http://localhost:8000 { "TableNames": [ "animals" ] } テーブルが作成できたら、データをインサートしてみます。今回は、AWS SDK for JavaScript v3を使ってデータを登録してみます。 まずは、必要なモジュールをインストールします。 npm install @aws-sdk/client-dynamodb uuid insert-data.jsに SDK を使って DynamoDB に登録する処理を書きます。 insert-data.js const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb"); const { v4: uuidv4 } = require('uuid'); (async () => { const client = new DynamoDBClient({ region: "ap-northeast-1", endpoint: "http://localhost:8000" }); const command = new PutItemCommand({ TableName: 'animals', Item: { "id": {"S": uuidv4()}, "Name": {"S": "pug"}, "AnimalType": {"S": "Dog"} } }); try { const results = await client.send(command); console.log('result:', results); } catch (err) { console.error(err); } })(); スクリプトを実行します。 $ node insert-data.js result: { '$metadata': { httpStatusCode: 200, requestId: 'c910a473-f2a4-41b2-8aab-5cdb6021d0ef', extendedRequestId: undefined, cfId: undefined, attempts: 1, totalRetryDelay: 0 }, Attributes: undefined, ConsumedCapacity: undefined, ItemCollectionMetrics: undefined } データが登録できたか、scan コマンドを実行して確認します。 $ aws dynamodb scan --endpoint-url http://localhost:8000 --table-name animals { "Items": [ { "AnimalType": { "S": "Dog" }, "id": { "S": "350d582d-b9cf-4c3f-9f5e-ef78b5493be6" }, "Name": { "S": "pug" } } ], "Count": 1, "ScannedCount": 1, "ConsumedCapacity": null } データが登録できているのが確認できました。お金をかけずに DynamoDB を使った開発ができそうですね。

はじめに サービスを開発していると、社内の人だけ見れるように公開したいということが多くあると思います。 その際に、接続元のIPをNetwork ACLやSecurity Groupで絞ってアクセスを制限するという方法があります。これは、社内ネットワークがしっかり構築されていてIPが統一されればいいですけど、そうでない場合各自のIPを許可していくのは面倒かなと思います。 そこでCookieでアクセスを絞れば各自ブラウザにセットするだけでいいので良いかなと思いました。それを実現するために行ったことを記載します。 ALBのリスナールールを利用する アクセスの制限はALBのリスナールールで行います。 リスナールールについてはこちら https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-update-rules.html 　 - host-header 　 - http-request-method 　 - path-pattern 　 - source-ip 　 - http-header 　 - query-string の条件でアクセス先を振り分けることができます。 Cookieをもとにアクセス先を振り分ける リスナールールでhttp-headerをもとにアクセス先を振り分けられうことがわかったので、ここでCookieを利用します。 ここからはALB構築されている前提で話します。 まず、ALBのリスナーというタブから「ルールの表示/編集」をクリックします。 すると、リスナールールを変更できると思うので以下のように設定します。 ルールID:1でHTTPヘッダーを選択してCookie=alb-listener-value=hogeと設定します。Cookieの名前や値は各自に任せます。なるべく推測されないものの方がより安全でしょう。 そして、デフォルトのルールは固定レスポンスで503とか返すようにしておけばいいと思います。 設定はこれで終わりです。 これでCookieに何もセットしないとアクセスできないけど、alb-listener-value=hogeをセットするとアクセスできるようになったと思います。

はじめに AWSの仮想サーバー構築用クラウドサービス「EC2」を用いて、PHPサイトを立ち上げた時に調べたことのまとめ。 全体の流れ・用語等についての記事であるため、具体的な手順については割愛しています。 目次 全体の流れ 項目別の詳細 用語 参考文献 全体の流れ AWSにサインアップ EC2インスタンスを作成 インスタンスをSSH接続で操作する Apache・PHP・MariaDBをインストール テスト用PHPファイルをアップロード Elastic IPを割り当て 各種設定を変更 項目別の詳細 1. AWSにサインアップ・2. EC2インスタンスを作成 　手順通りに進めるだけなので割愛。 3. インスタンスをSSH接続で操作する 　作成したインスタンスを操作する際には、端末からSSH接続をする。 　SSHクライアントとして、今回はTera Termを使用する。 　接続画面ではホストにパブリックDNS、ユーザーにec2-user、認証方式にSSHを選択し、インスタンス作成時に取得した秘密鍵を指定する。 4. Apache・PHP・MariaDBをインストール 　Tera Termのターミナル画面からApache、PHP、MariaDBをインストールする。 　まずはApacheから。 sudo -i // 管理者権限に切り替え（exitで戻す） yum install httpd //httpd（Apacheの別名）をインストール systemctl start httpd //Apacheを起動 systemctl status httpd //動作状況を確認 　続いてPHP。 yum install php //PHPをインストール sudo chown -R ec2-user /var/www/html //指定されたDirの所有者をユーザーに変更 //RオプションでDir下のすべてを変更できる 　MariaDB。 yum install mariadb mariadb-server //MariaDBをインストール systemctl start mariadb //起動、こちらもstatusで状態を確認できる 5. テスト用PHPファイルをアップロード 　お馴染みのindex.phpでハローワールドを出力してみる。 index.php <?php echo "Hello, World."; 　指定ホストにアクセスしてちゃんと画面に出力されれば成功。 6. Elastic IPを割り当て 　インスタンスに割り当てられたパブリックIP,パブリックDNSなどは、定期的に行われる再起動によって変動する。その度にAWSコンソールに行ってホストをコピペするのは非合理的なので、その変動を吸収するためのElastic IPというものを設定する。 　インスタンスに紐づけることで、そのElastic IPからのアクセスが可能になり、IPが固定化される。 　なお、使用料金は紐づけたインスタンスが稼働している間は発生しない。細かい手順は割愛。 7. 各種設定を変更 　最期に、実際に開発をするにあたり必要な機能や設定を変更する。 インスタンス再起動時、ApacheとMariaDBを自動で起動するように設定 TeraTerm systemctl enable httpd systemctl enable mariadb データベース設定 MariaDB update mysql.user set password=password('新しいパスワード') where user='ユーザー'; //ユーザーのパスワードを設定 grant all privileges on データベース.*to ユーザー@ホスト; //データベース内の全テーブルへのアクセス権を付与 flush privileges; //設定変更を反映 PDO使用設定 　デフォルトではPDOの設定が有効化されていないため、そのままPDOを使おうとするとエラーが出る。 TeraTerm sudo yum install php-pdo //pdo.soをインストール sudo yum install php-mysql //mysqlのドライバをインストール php.ini extension=pdo.so //追加 extension=pdo_mysql.so //追加 用語 　導入する中で様々な用語に出くわしたので、その備忘録。 リージョン 「地域」。物理サーバーの設置場所を指す。 AMI（Amazon Machine Image） 　サーバー構築用のソフトウェア（OS,サーバーアプリなど）のセット。 EBS（Elastic Block Store） 　インスタンスの内部ストレージ。HDDのようなもの。 VPC（Virtual Private Cloud） 　利用者ごとに与えられる、仮想ネットワーク空間。 yum 　UNIX系のパッケージ管理コマンド。 セキュリティグループ 　EC2インスタンス内に適用できるAWSのファイアウォール。 IAMユーザー 　IAM（AWSサービスへのアクセスを認可できるサービス）で設定されたユーザー。 参考文献 AWS EC2(Amazon Linux)にPHP7.4をインストール AWS EC2上にPHPサイトを立ち上げて、独自ドメインでアクセスできるようにするまでの全手順 Elastic IPの設定

EC2のライフサイクルマネージャーを使うと、スナップショットを定期的に作成することができます。設定方法と復元方法の手順を解説します。 流れ的には (1) ライフサイクルマネージャーでスナップショットを作成 (2) スナップショットからAMIを作成、AMIからEC2を作成 となります。 急に言われても無理なので事前に練習しておきましょう。 手順 (1) EC2インスタンス 今回のケースはWindowsのインスタンスで、Cドライブ30GB、Dドライブ40GBを使います。 (2) ライフサイクルポリシーを作成 EC2のライフサイクルマネージャーを選びます。 (3) ポリシータイプを選択 EBSスナップショットポリシーを選びます。 (4) ステップ 1 設定を指定 タグ名と値を入れます。EC2 にこのタグを登録するとスナップショットが作成されます。 例：Ec2Backup 1 例では値を 1 にしているので 0 や 2 では動作しません。 (5) ステップ 2 スケジュールを設定 毎日・毎週の時間を設定します。UTCなので日本時間23時だと14:00です。 保持タイプでいくつ残すかを指定することができます。 時間になると1時間以内にスナップショットが作成されます。実際40分後に作成されました。保持タイプの削除もタイムラグがあります。 (6) スナップショットの確認 時間を過ぎるとスナップショットが作成されます。 1時間くらいのタイムラグがあるので落ち着きましょう。 (7) スナップショットからAMIイメージの作成 スナップショット → AMI → EC2 となります。 (8) AMIイメージの作成 今回はCドライブとDドライブが必要です。DドライブのスナップショットIDを追加します。事前にメモを取っておいてください。 (9) AMIの起動からEC2の作成 AMIからEC2を起動します（説明略） ポイントをおさらい EC2ライフサイクルマネージャーを使うとEC2のスナップショットを作成できます。 毎日毎週、時間、保持数を指定できます。 作成も自動削除も1時間くらいのタイムラグがあるので落ち着きましょう。 スナップショットからAMIを作成してEC2です。 あとがき 古くからEC2 Windowsの実運用をしており、当時はライフサイクルマネージャーがなかったのでLambda python2.7で自動AMI作成を自作しました。Python2.7の終了と共に乗り換えました。便利になりました。

EC2内のvueファイルを更新しても、ブラウザに反映されない。 既にAWSにデプロイ済みのLaravelで作成したプロダクトについて、git pullで変更点をEC2に持って来た際に、ファイル内のコードは変更が反映されているのに、ブラウザで見ると反映されない事態が発生しました。 phpのファイルは問題なく変更が反映されているのに、なぜvueは反映されないのか。 ローカルで確認すると、期待通りに表示できています。 結論 app.jsの中身が更新できていませんでした。 よくよく確認するとmargeが前後した関係で、app.jsが古い状態になっていました。 レアケースかもしれませんが、一応シェアしておきます。

やりたいこと 社内で使用しているYamaha RTX1200のログをEC2に転送したい 環境 Windows10 Teraterm Ver4.105 RTX1200 AmazonLinux2 前提知識 AWSでVPCおよびVPNを作成できること Vim等のLinuxの基本操作ができること 構成図 Yamaha公式サイトより引用 手順 RTX1200を初期化 # cold start Password: RTFS formatting... Done. Restarting ... RTX1200をセットアップ > administrator Password:空白でOK # console character ascii ⇒初期状態は文字コードがSJISで文字化けするのでASCIIに変更 # console lines infinity ⇒デフォルトだと表示する行数に制限がかかっているため制限を外す RTX1200をインターネットに接続する 詳しい手順は環境によって変わるため割愛。 CLIでもWeb画面でも設定はできる。 ※PPPOE接続が必要な場合はISP情報が必要になるので用意しておくこと 最終的に画像のようにインターネットにつながっていればOK AWS（VPC）で作成したVPN接続のコンフィグを取得してRTX1200に投入する ※VPNの作り方はそのうち解説したいが今回は割愛 コンフィグ投入前にAWS,RTXでTunnel 1&2がDownしていることを確認しておくこと VPC　→　サイト間のVPC接続　→　あらかじめ作成したVPNを選択して設定のダウンロード ダウンロードしたコンフィグの#が無い行+IPSECのローカルIP設定をRTX1200に投入 最終的に画像のようにTunnel1＆２がUpになっていればOK VPNで接続したVPC内にEC2を作成 OSはAmazonLinux2、インスタンスタイプは好きなものを選択して起動。 プライベートIPアドレスでログインできることを確認。 syslogを設定 AmazonLinux2にはrsyslogがプリインストールされているのでインストールは不要。 　※rsyslogはsyslogと互換性がある。 /etc/rsyslog.confファイルの下記2行をアンコメントする。 module(load="imudp") input(type="imudp" port="514") # syslogはudpプロトコルで通信するためこの2行を有効化する必要がある /etc/rsyslog.d/フォルダの下に、下記内容のrtxlog.confファイルを作成。 local0.* -/var/log/rtxlog.log # "local0.*"と"/var/log/rtxlog.log"の間はスペースではなくTabを入力すること # localの数字は0～7まで好きな数字を選択できる rsyslogを再起動、syslogが来るか確認。 sudo service rsyslog restart tail -f /var/log/rtxlog.log # syslogからの書き込みがあれば表示される。 sudo logger -p local0.info "Test Alerm" # syslogが受信できているかテスト RTX1200のログをEC2に転送するよう設定変更 RTX1200にシリアル接続して以下のコマンドを実行。 syslog host "EC2のプライベートIP" syslog facility local0 tail -fしたままになっているEC2でRTX1200からのsyslogが受信できていることを確認して作業完了。 今後はログローテーションなど他にも実装する必要があるものがあるので随時紹介していきたい。

aws cli の docker イメージが公式から提供されていました。 awsコマンドで aws cli の docker コンテナを簡単に起動できるように設定してみます。 設定してみる awsコマンドで docker コンテナが立ち上がるように、 alias を設定します。 alias aws='docker run --rm -it -v ~/.aws:/root/.aws amazon/aws-cli' alias が設定できているか確認します。 $ aws --version aws-cli/2.2.37 Python/3.8.8 Linux/4.19.128-microsoft-standard docker/x86_64.amzn.2 prompt/off ~/.awsに認証情報がない場合は、configureコマンドで作成します。 $ aws configure AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: ap-northeast-1 Default output format [None]: json ホスト側に認証情報が作成されているか確認します。 $ cat ~/.aws/credentials [default] aws_access_key_id = dummy aws_secret_access_key = dummy おわりに docker コンテナで aws cli の設定できるのは便利ですね。aws cli のバージョンが今後上がったとしても、docker image のバージョンを変えるだけで任意のバージョンに簡単に変更できるので、使い道は多そうです。

Infrastructure Design for Real-time Machine Learning Inference - The Databricks Blogの翻訳です。 この記事は、HeadspaceのシニアソフトウェアエンジニアであるYu Chenによるものです。 Headspaceのコア製品は、マインドフルネス、瞑想、睡眠、エクササイズ、フォーカスコンテンツを通じてユーザーの健康、幸福を改善することにフォーカスしたiOS、Android、webベースのアプリケーションです。ユーザーの生涯の旅において、一貫性のある習慣を確立するために、適切かつパーソナライズされたコンテンツをレコメンデーションすることで、ユーザーのエンゲージメントを高めるために、機械学習(ML)モデルは我々のユーザー体験におけるコアとなります。 即座に意思決定を行うためにデータを活用する場合には、MLモデルに入力されるデータは、多くのケースで最も重要となりますが、実際のところ、顧客データが取り込まれ、変換された後、機械学習と分データ分析チームが活用するまで、長い間そのままの状態で放置されています。 リアルタイムでの洞察、意思決定を行うためにユーザーデータを活用する方法を見つけることは、Headspaceのアプリのような顧客接点のある製品は、エンドツーエンドのユーザーフィードバックのループを劇的に短縮できることを意味します。直前にユーザーが実行したアクションは、ユーザーに対してより適切かつパーソナライズされ、かつ、文脈を考慮したコンテンツのレコメンデーションを実現します。 これによって、我々のモデルは、ユーザーの日々の、あるいはそれぞれのセッションを通じてアップデートされる動的な特徴量と連携できるようになります。これらの特徴量には、以下のようなものが含まれます。 休眠コンテンツに対する現在のセッションの離脱率 最近のユーザーの検索単語に対する意味のエンベッディング。例えば、ユーザーが「重要な試験に備える」と検索した場合には、その目標を達成できるように、MLモデルはフォーカスのテーマの瞑想により高い重みを割り当てます。 ユーザーの身体データ(例：過去10分で歩数、心拍数が増加した場合には、移動、エクササイズのコンテンツをレコメンドします) ユーザー体験を考慮して、Headspaceの機械学習チームはインフラストラクチャのシステムを、パブリッシング、レシーバー、オーケストレーション、サービングレイヤーに分解することでソリューションを設計しました。このアプローチでは、MLモデルに対するリアルタイム推論機能を提供するために、DatabricksにおけるApache Spark™の構造化ストリーミング、AWS SQS、LambdaとSageMakerを活用しました。 この記事では、我々のアーキテクチャに対する技術的ディープダイブを行います。リアルタイム推論に対する要件を説明した後で、従来型のオフラインMLワークフローを導入する際の課題を議論します。キーとなるアーキテクチャ上のコンポーネントの詳細を議論する前に、アーキテクチャの概要を説明します。 リアルタイム推論の要件 ユーザーコンテンツをパーソナライズするためのリアルタイム推論を行うためには、以下のことが必要となります。 クライアントアプリ(iOS、Android、web)上でのユーザーの適切なイベント(アクション)に応じた取り込み、処理、転送 リアルタイム推論モデルに用いられる特徴量セットを拡張するオンライン特徴量の高速な計算、格納、検索(m秒のレーテンシー) ダウンタイムを最小化(理想的には回避)しつつも、オンラインでサーブされるモデルをオンライン特徴量ストアと同期できるように、リアルタイム推論モデルのサービング及びリロード 我々のエンドツーエンドのレーテンシーの目標値(ユーザーのイベントがKinesisストリームに転送され、リアルタイムの推論予測が利用できるようになるまで)は30秒でした。 従来のMLワークフロー導入における課題 上の要件は、日次バッチで予測を行うオフラインモデルにおいては、多くのケースで解決されない(解決する必要のない)課題となります。ETL/ELTデータパイプラインから取得、変換されるレコードから推論を行うMLモデルは、通常、生データに対して数時間のリードタイムを必要とします。従来、MLモデルのトレーニング、サービングワークフローには、以下のステップが含まれており、数時間周期あるいは日次のジョブで定期的に実行されていました。 上流のデータストアから適切な生データの取り出し: Headspaceにおいては、我々のデータエンジニアリングチームによって維持されている上流のデータレイクにクエリーを実行するためにSpark SQLを使用しています。 リアルタイム推論の場合： 我々は1秒あたり最大数千の予測リクエストを経験しており、バックエンドデータベースに対するSQLクエリーの使用は許容できないレーテンシーを引き起こしました。モデルのトレーニングでは完全なデータセットを取得する必要がありますが、リアルタイムの推論においては多くの場合、同じデータにおける個々のユーザーのサブセットデータのみが必要となります。このため、我々は個々のユーザー特徴量の読み書きが数m秒で行えるAWS Sagemaker Online Feature Groupsを使用しています(図のStep 3)。 SQLとPythonを組み合わせたデータ再処理の実行(特徴量エンジニアリング、特徴量抽出など) リアルタイム推論の場合： 生のイベントデータのSpark Structured Streamingのマイクロバッチを、Sagemaker Feature Store Groupsからのリアルタイム特徴量で拡張します。 モデルのトレーニング、適切なエクスペリメントのメトリクスを記録: MLflowを用いることで、Databricksノートブックのインタフェース内から、異なるエクスペリメントの実行におけるモデルおよびパフォーマンスを記録します。 ディスクへのモデルの永続化: MLflowがモデルを記録すると、MLライブラリのネイティブフォーマットを用いてシリアライズを行います。例えば、scikit-learnのモデルはpickleライブラリを用いてシリアライズされます。 適切な推論データセットにおける予測の実行: この場合、我々のユーザーベースに対する新たなコンテンツのレコメンデーションを行うために、新規にトレーニングしたレコメンデーションモデルを使用します。 ユーザーに予測を提供するために永続化します。これは、MLの予測結果をエンドユーザーに提供する際の、本番運用のアクセスパターンに依存します。 リアルタイム推論の場合: ML-poweredというタブにナビゲートしたエンドユーザーが予測結果を取得できるように、予測結果を我々の予測サービスに登録します。あるいは、予測結果を別のSQLキューに転送し、コンテンツのレコメンデーションをiOS/Androidのプッシュ通知で送信します。 オーケストレーション: 従来型のバッチ推論モデルでは、異なるステージ・ステップをスケジュール、調整するためにAirflowのようなツールを活用します。 リアルタイム推論の場合: 適切なメッセージングフォーマットに圧縮・解凍するために軽量なLambda関数を用い、Sagemakerエンドポイントを起動して必要となる事後処理、永続化を実行します。 ユーザーはHeadspaceアプリ内で行うアクションによってイベントを生成し、最終的には、Spark構造化ストリーミングで処理するためにKinesisストリームに転送されます。ユーザーのアプリは、我々のバックエンドサービスに対してREST HTTPリクエストを行い、ユーザーIDとどのタイプのMLレコメンデーションを取得するのかを示す特徴量フラグを渡すことで、ニアリアルタイムの予測結果を取得します。アーキテクチャの他のコンポーネントについては、以下で詳細を説明します。 パブリッシング・サービングレイヤー：モデルトレーニング、デプロイメントのライフサイクル MLモデルはDatabricksノートブックで開発され、MLflowエクスペリメントを通じて、レコメンデーションシステムに対する、Recall@kのような、コアのオフラインメトリクスを用いて評価されます。HeadspaceのMLチームは、MLflowにおけるPython関数モデルフレーバークラスを拡張するラッパークラスを記述しました。 参考資料 Python # this MLflow context manager allows experiment runs (parameters and metrics) to be tracked and easily queryable with MLModel.mlflow.start_run() as run: # data transformations and feature pre-processing code omitted (boiler-plate code) ... # model construction lr = ElasticNet(alpha=alpha, l1_ratio=l1_ratio, random_state=42) # training lr.fit(train_x, train_y) # evaluate the model performance predicted_qualities = lr.predict(test_x) (rmse, mae, r2) = eval_metrics(test_y, predicted_qualities) # Wrap the model in our custom wrapper class model = ScikitLearnModel(lr) model.log_params(...) model.log_metrics(...) # record the results of the run in ML Tracking Server # optionally save model artifacts to object store and register model (give it a semantic version) # so it can be built into a Sagemaker-servable Docker image model.save(register=True) githubで見る HeadspaceのMLチームのモデルラッパークラスは、MLflowモデルのDockerイメージを構築するのに必要となるメタデータ、依存関係、モデルアーティファクトを格納するMLモデルのS3バケットにディレクトリを作成し、数多くの実装ロジックを実行できるように、MLflow自身のsave_modelメソッドを呼び出します。 次に、上でS3に保存したモデルを指し示す正式なGithubリリースを作成します。これはCircleCIのようなCI/CDツールによって取り出され、MLflowモデルをテスト、ビルドし、最終的には、Sagemakerモデルエンドポイントにデプロイされるように、AWS ECRにプッシュされます。 リアルタイムモデルのアップデート、リロード 我々は頻繁にモデルの再トレーニングを行いましたが、実運用されているリアルタイム推論モデルのアップデートは厄介なものです。AWSには、実際にサービングしているSagemakerモデルをアップデートするのに活用できる、様々なデプロイメントパターン(gradual rollout、canaryなど)があります。しかし、リアルタイムモデルでは、オンライン特徴量ストアとの同期も必要となり、Headspaceのユーザーベースにおいてアップデートを完了するには30分を必要としました。モデルイメージをアップデートするたびにダウンタイムを発生させたくなかったので、モデルイメージと特徴量ストアが確実に同期するように注意深くなる必要がありました。 例えば、HeadspaceユーザーIDを協調フィルタイングモデルのユーザーシーケンスIDにマッピングするモデルを例に取ります。我々の特徴量ストアには、最も頻繁に更新されるユーザーIDとシーケンスIDのマッピングが含まれている必要があります。ユーザーの数が完全に静的であり続けない限り、モデルを更新した場合、我々のユーザーIDは推論の際に古いシーケンスIDにマッピングされ、ターゲットとしたユーザーではなく、ランダムなユーザーに対する予測を生成することになってしまいます。 ブルー・グリーンアーキテクチャ この問題に取り組むため、DevOpsのブルー・グリーンデプロイメントのプラクティスに倣ったブルー・グリーンアーキテクチャを導入しました。ワークフローは以下のようになります。 2つの並列のインフラストラクチャを維持します(この場合は、2つの特徴量ストアのコピー)。 一方をプロダクション環境に指定し、Lambdaを経由して特徴量と予測のリクエストをこちらにルーティングします。 モデルのアップデートを行うシアには、補助用のインフラストラクチャ(「ブルー」環境)をアップデートするためのバッチプロセス/スクリプトを使用します。アップデートが完了したら、特徴量・予測のLambdaがブループロダクション環境をポイントするように切り替えます。 モデル(および対応する特徴領ストア)をアップデートするたびにこれを繰り返します。 レシーバーレイヤー：Apache Sparkの構造化ストリーミングスケジュールジョブによるイベントストリームの取り込み Headspaceのユーザーイベントアクション(アプリへのログイン、特定のコンテンツの再生、サブスクリプションの更新、コンテンツの検索など)は、集約されてKinesisデータストリームに転送されます(図のStep 1)。Kinesisストリームからのデータを処理するために、DatabricksじのSpark構造化ストリーミングフレームワークを活用しました。構造化ストリーミングには以下のようなメリットがあります。 データサイエンティスト、データエンジニア、アナリストで共有可能な統合された言語(Python/Scala)、フレームワーク(Apache Spark)を活用できるので、複数のHeadspaceチームで、慣れ親しんだデータセット・データフレームAPIと抽象化を用いてユーザーデータを取り扱うことができます。 我々のチームがビジネス要件を満たすためにカスタムのマイクロバッチロジックを実装することができます。例えば、ユーザーごとにカスタムのイベントタイムウィンドウやセッションのウォーターマークロジックに基づくマイクロバッチを定義し実行することができます。 MLエンジニアにとって重荷となっている、インフラストラクチャの管理工数を劇的に削減できるDatabricksのインフラストラクチャツールを活用できます。これらのツールには、ジョブのスケジュール、自動リトライ、効率的なDBUクレジットプライシング、イベント失敗を知らせるメール通知、ビルトインのSparkストリーミングダッシュボード、そして、ユーザーアプリのイベントアクティビティに応じて迅速にオートスケールする機能が含まれます。 構造化ストリーミングは、連続的なイベントストリームをそれぞれのチャンクに分割し、到着し続けるイベントを小さなマイクロバッチデータフレームとして処理するためにマイクロバッチを使用しています。 ストリーミングデータパイプラインは、イベント時間(クライアントデバイスで実際にイベントが発生した時間)と処理時間(データがサーバーに到着した時間)を区別する必要があります。ネットワーク分断、クライアント側のバッファリング、他のホストの問題などが、これらの時間に関して無視できない不一致を引き起こします。構造化ストリーミングAPIでは、シンプルなロジックのカスタマイゼーションによって、これらの不一致をハンドリングすることができます。 Python df.withWatermark("eventTime", "10 minutes") \ .groupBy( "userId", window("eventTime", "10 minutes", "5 minutes")) githubで見る 以下のパラメーターを用いて構造化ストリーミングジョブを設定しました。 最大同時実行数は1 無制限のリトライ 新規スケジュールジョブクラスター(All-Purposeクラスターではありません) スケジュールジョブクラスターを活用することで、関係するインフラストラクチャの障害発生確率を削減しつつも、DBUコストを劇的に引き下げることができました。障害のあるクラスターでジョブがスタートした場合、これには依存関係、インスタンスプロファイルの設定ミス、アベイラビリティゾーンのキャパシティ不足などが考えられますが、背後のクラスターの問題が解決するまでこのジョブは失敗しますが、別のクラスターのジョブは干渉を避けることができます。 次に、クライアント側のユーザーイベントを集約するように設定されたAmazon Kinesisストリームから読み込みを行うようにストリームクエリーをポイントします(図のStep 2)。以下のようなロジックでストリームクエリーが設定されます。 Python processor = RealTimeInferenceProcessor() query = df.writeStream \ .option("checkpointLocation", "dbfs://pathToYourCheckpoint") \ .foreachBatch(processor.process_batch) \ .outputMode("append") \ .start() githubで見る ここで、outputModeはストリーミングのシンクに対してどのように書込みを行うのかのポリシーを定義し、3つの値append、complete、updateを指定することができます。我々の構造化ストリーミングジョブは到着するイベントのハンドリングですので、「新規」レコードのみを処理するようにappendを選択しました。 失敗したストリーミングクエリーをgracefulに再開できるようにチェックポイントを設定することは良いアイデアです。これによって、失敗あの直後から処理を「再生」することができます。 ビジネスユースケースに応じて、ASAPでそれぞれのマイクロバッチをスタートするようにprocessingTime = "0 seconds"を設定することで、レーテンシーを削減する選択も可能です。 Python query = df.writeStream \ .option("checkpointLocation", "dbfs://pathToYourCheckpoint") \ .foreachBatch(process_batch) \ .outputMode("append") \ .trigger(processingTime = "0 seconds") \ .start() githubで見る さらに、我々のSpark構造化ストリーミングジョブクラスターには、Sagemaker Feature Groupsとやりとりを行い、予測ジョブのSQSキューにメッセージを送信できるように適切なIAMポリシーが設定された特別なEC2インスタンスプロファイルが設定されています。 最終的には、それぞれの構造化ストリーミングジョブには異なるビジネスロジックを組み込む必要があるので、マイクロバッチごとに起動される異なるマイクロバッチ処理関数を実装する必要がありました。 我々のケースでは、最初にAWS Sagemaker Feature Storeでオンラン特徴量を計算・更新するprocess_batchを実装し、ユーザーイベントをジョブキューに転送しました(Step 3)。 Python from pyspark.sql.dataframe import DataFrame as SparkFrame class RealTimeInferenceProcessor(Processor): def __init__(self): self.feature_store = initialize_feature_store() def process_batch(self, df: SparkFrame, epochID: str) -> None: """ Concrete implementation of the stream query’s micro batch processing logic. Args: df (SparkFrame): The micro-batch Spark DataFrame to process. epochID (str): An identifier for the batch. """ compute_online_features(df, self.feature_store) forward_micro_batch_to_job_queue(df) githubで見る オーケストレーションレイヤー：イベントキューと特徴量トランスフォーマーとしてのLambdaの分離 Headspaceのユーザーは、我々のリアルタイム推論モデルが最新のレコメンデーションを生成するために処理するイベントを生成します。しかし、ユーザーイベントアクティビティのボリュームは均等に分布していません。数多くの増減があり、我々のユーザーは特定の時間帯に最もアクティブになります。 SQL予測ジョブキューに投入されたメッセージは、以下の処理を行うAWS Lambda関数(図のStep 4)で処理されます。 メッセージを解凍し、レコメンデーションの対象となるユーザーに関するオンライン・オフライン特徴量を取得します(図のStep 5)。例えば、ユーザーの利用期間、性別、言語などの属性でイベントの時系列・セッションベースの特徴量を拡張する場合があります。 最終の前処理ビジネスロジックを適用します。協調フィルタリングモデルで活用できるHeadspaceユーザーIDからユーザーシーケンスIDへのマッピングなどが挙げられます。 Sagemakerでサーブされる適切なモデルを選択し、入力特徴量を与えて起動します(図のStep 6)。 下流の目的地にレコメンデーションを転送します(図のStep 7)。実際の位置は、ユーザーにレコメンデーションコンテンツをプルダウンしてもらうのか、ユーザーにプッシュでレコメンデーションするのかに依存します。 プル: この方法には、クライアントのアプリのリクエストに基づき、Headspaceアプリの数多くのタブに最新のパーソナライズされたコンテンツを提供することに責任を持つ、内部の予測サービスへの最終的なレコメンデーションコンテンツの永続化が含まれます。以下に、アプリの「Today」タブにパーソナライズされたレコメンデーションをユーザーに提供する、リアルタイム推論インフラストラクチャの実験の例を示します。 プッシュ: この方法には、プッシュ通知、あるいは、アプリ内のモーダル上のプッシュレコメンデーションのために別のSQSキューへのレコメンデーションの送信が含まれます。例として以下の画像をご覧ください。上はユーザーによる睡眠コンテンツに対する最近の検索によってトリガーされるアプリ内モーダルプッシュレコメンデーションであり、下は最近ユーザーが完了したコンテンツに基づくiOSのプッシュ通知です。 特定の瞑想を完了するか、検索を行った数分のうちに、ユーザーに対するコンテキストを最優先としつつも、適切な次のコンテンツを提供するためにこれらのプッシュ通知が行われます。 さらに、イベントキューを活用することで、予測ジョブのリクエストを再トライすることができます。予測ジョブが特定期間で完了しなかった場合に、リトライのために別のLambda関数が起動されるように、SQSキューに対して小規模のタイムアウトウィンドウ(10-15秒)を設定することができます。 まとめ インフラストラクチャ、アーキテクチャの観点から、異なるサービス間で柔軟に引き渡しを行えるポイントを設計することに優先度を置くということが主な学びとなりました。我々の場合、パブリッシング、レシーバー、オーケストレータ、そしてサービングレイヤーとなります。例えば、 我々の構造化ストリームジョブが予測SQSキューに送信する際のメッセージペイロードにはどのようなフォーマットを使うべきか？ それぞれのSagemakerモデルが期待するモデルのシグネチャとHTTP POSTペイロードはどのようなものであるべきか？ 本番環境で安全かつ信頼性高く再トレーニングしたモデルを更新できるように、どのようにモデルイメージとオンライン特徴量ストアを同期すべきか？ これらの疑問に積極的に取り組むことで、複雑のMLアーキテクチャの様々なコンポーネントを、小規模かつモジュール化されたインフラストラクチャのセットに分離することができました。 HeadspaceのMLチームは、今でもこのインフラストラクチャでプロダクションユースケースをロールアウトし続けていますが、初期のA/Bテストと実験によって、他のHeadspaceの取り組みや業界ベンチマークと比較して、コンテンツのスタート率、コンテンツの完了率、直接/合計のプッシュ開封率に大きな改善が認められました。 リアルタイム推論の能力を持つモデルを活用することで、Heaspaceはユーザーのアクションからパーソナライズされたコンテンツレコメンデーションに要するリードタイムを劇的に削減することができました。現在のセッション内での、最近の検索、コンテンツの開始・離脱・一時停止、アプリ内のナビゲーション、バイオメトリクスデータのようなイベントストリームは、ユーザーがHeadspaceアプリを操作している間であっても、ユーザーに対して最新のレコメンデーションを継続的に提供することができます。 Databricksにおける機械学習に関して知りたいのでしたら、Data+AI Summit 2021のキーノートで説明されている概要をご覧ください。また、Databricksにおける機械学習のホームページにあるリソースを参照ください。 Headspaceに関しては、www.headspace.comをご覧ください。 Databricks 無料トライアル Databricks 無料トライアル

これは何 AWS SSMでCyberduck(FTPクライアントソフト)を使用して、Private EC2へファイル転送してみました。 FTPソフトはWinSCPとか他のでもいけると思います。（動作検証はしてませんが） 早速やってみた IAMロールを作成 AmazonSSMManagedInstanceCore ポリシーを含むロールを作成 EC2へアタッチする 先ほど作成したロールをEC2にアタッチします。 AWS CLI v2のインストール、configureコマンドで情報入力 今回は、direnvを使用し、環境変数を定義しました。 こんな感じで export AWS_ACCESS_KEY_ID="" export AWS_SECRET_ACCESS_KEY="" export AWS_DEFAULT_REGION="" Session Manager pluginのインストール 以下より、マシンに合わせて選択し、インストール。 https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html 鍵ファイルのパーミッションを変更 $ chmod 600 CMS秘密鍵 AWS CLIで利用するIAMユーザーを作成 IAMポリシーの作成 以下のポリシーでSSHが可能。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "ssm:StartSession", "ssm:TerminateSession", "ssm:ResumeSession", "ssm:DescribeSessions", "ssm:GetConnectionStatus" ], "Effect": "Allow", "Resource": [ "*" ] } ] } IAMユーザーの作成 上記のポリシーを付与したIAMユーザーを作成。 プログラムによるアクセスを許可。 生成されたアクセスキーとシークレットアクセスキーを先ほどの環境変数に定義する。 ポートフォワーディングをする $ aws ssm start-session --target 【インスタンスID】 --document-name AWS-StartPortForwardingSession --parameters "portNumber=22,localPortNumber=10220(任意)" すると、以下の文字を吐きます。 Starting session with SessionId:xxxxx Port 10220 opened for sessionId xxxxx Waiting for connections... Cyberduckでファイル転送 サーバー名 : localhost ポート名 : 10220 ユーザー名 : OSユーザー名 SSH Private Key : 秘密鍵のFull Path ターミナルがこんな文字列を吐くようになったら、接続成功です。 Connection accepted for session xxxxx 参考 https://hikari-blog.com/ec2-session-manager/ https://blog.denet.co.jp/ssm-winscp-upl/ https://qiita.com/hayao_k/items/78b5bfe030ad8a053e93 参考にさせていただきました。ありがとうございます。

目的 災害対策として、オンプレサーバのバックアップを、クラウドにも保存する。いわゆるディザスタリカバリ。 クラウドサービスの選定 Amazon s3を選定。理由は、オンプレサーバのバックアップ先(NAS)にs3と連携できる機能が標準で付いていたため。 ざっくりな流れ AWS側でs3バケット作成 ↓ オンプレ側でs3への接続設定 s3バケット作成 妙な言い回しでひっかかる設定項目があったが、既に先人の知恵がございましたので、ここでの説明は割愛。 そして先人に盛大なる感謝。 S3のブロックパブリックアクセスが怖くなくなった セキュリティを確保するため、オンプレサーバのグローバルIPからs3へのアクセスのみ許可するようなポリシーを設定します。(JSON形式で) { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::bucket-name", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "xxx.xxx.xxx.xxx/32" ] } } } ] } 注意すべきはこのときです！ グローバルIPを間違えて入力してしまったもんなら、もうそのバケットに対して何も操作出来なくなります。 もしバケット操作不可になった場合は、ルートユーザでAWSマネジメントコンソールにログインすれば、ポリシー変更なり削除なりの操作が可能です。 なんらかの代行サービスを経由してAWSアカウントを取得している場合は、ルートユーザでの操作ができない場合がありますので、ご注意ください。 私の場合はまさにルートユーザでの操作ができないタイプのサービスでしたので、バケットがずーっと残ったままになっていますorz オンプレ(NAS)からS3への接続設定 NASの機種によると思いますが、必要なのはたいてい 　1.アクセスキーID 　2.シークレットアクセスキー 　3.バケット名 くらいかと思われます。 1と2は、IAMユーザのキーになります。間違ってもルートユーザのキーは作成しないように！ おわりに VPCやらサブネットやらセキュリティグループやらの設定に比べたら、S3の設定は全然難しくありませんでした。 でも、一歩間違えるとバケット操作できなくなる可能性がありますので、ご注意ください。

はじめに Terraformを使ってみるとTerraformでコードを書く よりも 既存リソースをTerraformにインポートすることが結構あります。 公式のドキュメントを読めばやり方はわかります。 ただ、少しわかりづらい箇所もあるので細かい部分も説明しながらインポート手順を説明していきます 前提 AWSアカウント作成済 AWSリソース作成済(今回はこちらの記事で作成したlambda関数をリソースとして使用します。他のリソースでも構いません) terraform インストール済 (参考: https://dev.classmethod.jp/articles/beginner-terraform-install-mac/) terraformer インストール済 (参考: https://beyondjapan.com/blog/2020/05/terraformer-import-existing-infrastructure/) ディレクトリ構成 root ┣━　test ┃ ┣━ provider.tf ┃ ┣━ terraform.tfvars ┃ ┗━ lambda.tf 　　　　┗━ .gitignore インポートするための必要最低限のファイルとを用意します .gitignoreはGiHub等にAWSのキーをpushしないためのファイルなのでローカルだけで作業する場合は不要です。 provider.tf variable "aws_access_key" {} variable "aws_secret_key" {} provider "aws" { access_key = var.aws_access_key secret_key = var.aws_secret_key region = "us-east-2" } terraform.tfvars # AWSのアクセスキーとシークレットキーを記述 aws_access_key = "xxxxxxxxxx" aws_secret_key = "xxxxxxxxxx" lambda.tf # ここにlambdaのリソースをインポートしていきます .gitignore # .tfstate files *.tfstate *.tfstate.* # .tfvars files *.tfvars # terraformer import fils */generated/ インポート方法 Terraformで既存リソースをインポート まずは terraform リソース名 でブラウザ検索してみましょう 今回はlambdaのリソースをインポートするので terraform lambdaで検索すると Terraform公式のリンクが表示されます https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function こちらのリンクに記載されているExample Usageの章を参考に最低限のリソースの雛形を書きます lambda.tf # "test_lambda"の部分は任意の名前でOK resource "aws_lambda_function" "test_lambda" { } これで雛形が完成です 次にインポートのコマンドを調べます Importの章を確認しましょう https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function#import ここにインポートの際に必要なコマンドが記載されています $ terraform import aws_lambda_function.test_lambda my_test_lambda_function こちらを解釈すると $ terraform import aws_lambda_function.(インポート先の名前) (インポートしたいlambda関数の名前) となります。 今回はインポート先の名前: test_lambda 、インポートしたいlambda関数の名前: start_stop_ec2_inatanceなのでそちらを使用してターミナル上でコマンド実行します user@user test % terraform import aws_lambda_function.test_lambda start_stop_ec2_instance aws_lambda_function.test_lambda: Importing from ID "start_stop_ec2_instance"... aws_lambda_function.test_lambda: Import prepared! Prepared aws_lambda_function for import aws_lambda_function.test_lambda: Refreshing state... [id=start_stop_ec2_instance] Import successful! The resources that were imported are shown above. These resources are now in your Terraform state and will henceforth be managed by Terraform. Import successful!のログが出れば成功です インポートする際の注意点 一点注意して頂きたいのはリソースごとにインポートコマンドの書き方が異なります。 先ほどのlambdaの場合はコマンドの末尾にlambda関数の名前を入力していましたが、 例えばEC2インスタンスの場合は、以下のようにコマンドの末尾にはインスタンスのidを入力します $ terraform import aws_instance.web i-12345678 参照：https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance#import インポートのコマンドはリソースごとに調べて実行しましょう Terraformerでtfファイルを出力 Terraformによるインポートが終わったら、Terraformerを使ってリソースの中身を書いていきます。 GitHubに必要なコマンドとリソース名が掲載されているのでこちらを使用します https://github.com/GoogleCloudPlatform/terraformer/blob/master/docs/aws.md 基本的なコマンドは以下の通りです $ terraformer import aws --resources=(リソース名) --regions=(リージョン名) まずインポートしたいリソース名をGitHub上で検索します。 検索する理由はTerraformer上でのリソース名が一般的なリソース名を省略した形になっている場合があるからです 例えばsecurity_groupをインポートしたい場合、GitHub上で　検索するとsgで入力してね。と書いてあります 今回はlambdaをインポートしたいのでGitHub上で調べてみると、そのままlambdaがリソース名として使えそうです リソース名がわかったらコマンドをターミナルで入力しましょう user@user test % terraformer import aws --resources=lambda --regions=us-east-2 2021/09/07 09:05:11 aws importing region us-east-2 2021/09/07 09:05:14 aws importing... lambda 2021/09/07 09:05:16 aws done importing lambda 2021/09/07 09:05:16 Number of resources for service lambda: 1 2021/09/07 09:05:16 Refreshing state... aws_lambda_function.tfer--test_lambda 2021/09/07 09:05:19 Filtered number of resources for service lambda: 1 2021/09/07 09:05:19 aws Connecting.... 2021/09/07 09:05:19 aws save lambda 2021/09/07 09:05:19 aws save tfstate for lambda コマンドが成功すればgeneratedディレクトリが生成され、その中にlambda_function.tfファイルも生成されます その中身を先ほど作成したlambda.tfファイルの雛形に書き写します lambda.tf resource "aws_lambda_function" "test_lambda" { environment { variables = { INSTANCE_ID = "i-xxxxxxxxxx" } } function_name = "start_stop_ec2_instance" handler = "lambda_function.lambda_handler" memory_size = "128" package_type = "Zip" reserved_concurrent_executions = "-1" role = "arn:aws:iam::xxxxxxxxxx:role/start_stop_instance_lambda" runtime = "python3.8" source_code_hash = "xxxxxxxxxxxxxxxxxxxx" timeout = "3" tracing_config { mode = "PassThrough" } } ここで一点注意して欲しいのがINSTANCE_ID = "i-xxxxxxxxxx"のようにハードコーディングされている箇所があることです GitHub等にpushする際は変数化してハードコーディングを回避しましょう インポートできたか確認 最後に既存リソースとTerraform上のリソースに差分がないかterraform planを実行して確認します user@user test % terraform plan aws_lambda_function.test_lanmbda: Refreshing state... [id=start_stop_ec2_instance] No changes. Your infrastructure matches the configuration. Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed. No changes.と出れば差分なくインポート完了です 終わり 今回はlambdaを使って既存リソースのインポートを行いました 他のリソースでも同様の手順でインポートできるのでぜひやってみてください

はじめに Amazon Lightsail 上の WordPress に Google Adsense の設定ファイル (ads.txt)を導入します。 導入しないと、以下のようなエラーが出ます。 手順 ads.txtファイルのダウンロード Google AdSense のダウンロードリンクからads.txtをダウンロードします。 ads.txtを開くと次のような1行が書いてあります。 google.com, <some number>, DIRECT, <some number> このads.txtをサイトのルードレベルに保存すればOKです。 Lightsail に導入する AWS コンソール から Lightsail にアクセスして、ターミナルを起動します。 ターミナルからads.txtを作成します。 $ cat <ads.txtの1行> > /home/bitnami/apps/wordpress/htdocs/ads.txt $ sudo chown bitnami:daemon /home/bitnami/apps/wordpress/htdocs/ads.txt カンタンですね。

前回の続き 目的 自分用のメモ 単語の意味と役割を掴んでイメージを把握する EC2を運用する上で出てきた単語 EC2 Amazon Elastic Compute Cloud AWSのクラウド上でサーバーを実行するためのサービス 単一ではなく複数の仮想サーバー（インスタンス）を実行する EC2を利用することで、OSを乗せた仮想環境をクラウド上にすばやく作ることができる インスタンスタイプ 用途別に集められた「インスタンスファミリー」と、CPUなどのスペックを示す「インスタンスサイズ」から構成されている インスタンスファミリーの数字は「世代」を表していて、数字が大きければ大きいほど新しい インスタンスファミリー 「汎用」「コンピューティング最適化」「メモリ最適化」「高速コンピューティング」「ストレージ最適化」の5種類に分類される それぞれのシステムによって設定する セキュリティグループ EC2インスタンスなどに適用するファイアウォール機能で、主にVPCリソースのトラフィックを制御するのに使われる EC2インスタンスへのアクセスを"許可"したり、トラフィックを"制御"する役割がある ファイアーウォールとはネットワークの門番のこと(ウイルス等から守る) インバウンドルール セキュリティグループに関連付けられたインスタンスにアクセスできるルール アウトバウンドルール セキュリティグループに関連付けられたインスタンスからどの送信先にトラフィックを送信できるか（トラフィックの送信先と送信先ポート）を制御するルール ネットワークACL サブネットに属するすべてのインスタンスに対して適用されるファイアウォール 許可と拒否のルールを定義する EC2のIPアドレスの種類 パブリックIPアドレス インターネットから接続できるアドレス インスタンスを再開しても同じIPアドレスは付与されない プライベートIPアドレス EC2インスタンスにアタッチされているすべてのENIに対して、個別に付与できるIPアドレス インスタンスを再開したときに同じIPアドレスのままになる ENI Elastic Network Interface 仮想ネットワークインターフェースのこと インスタンスにはデフォルトで１つのENIがアタッチ（仮想化環境に追加すること）されており、必要に応じて複数のENIをアタッチできます。 EIP 固定でEC２インスタンスに付与できるパブリックIPアドレス 開放しない限り,付与されたまま使うことができる キーペア 　* EC2にログインするための公開鍵と秘密鍵のためのサービス 　* インスタンスにSSHで接続するため、インスタンスに対して設定する公開鍵 　* SSHの仕組みとして公開鍵に対応する秘密鍵を持っているユーザーだけがSSHでインスタンスにログインすることが可能 　* キーペアを持つことでログインの安全性が保たれている Amazon EBS Elastic Block Store もっともよく使われるEC2インスタンスのストレージ OSやアプリケーション、ユーザーのデータなどを格納する

AWSでSSL化の際httpアクセスをhttpsへリダイレクトするしないのロードバランサー（リスナー）の設定 リダイレクトさせる設定 リダイレクトさせない設定 参考記事：https://qiita.com/nakanishi03/items/3a514026acc7abe25977

概要 2020年10月からdocker hubのリポジトリからpullする時に未ログインした状態でpullすると任意のIP単位で制限をかけるような仕様を追加した。 これを解決するにはdocker loginをするしかない。 また、code buildはawsのマネージドサービスで動いているため、数回動かしただけでrate limitsエラーが表示されてしまう。 このエラーを回避するためにはcode buildのbyildspec.yamlでコンテナをビルドする前にdocker loginをする必要がある。 詳しくは以下。 buildspec.yamlの例 変数はcode build経由で渡すなりsecret manager経由で渡すなり、セキュリティ要件とやりやすさを考えてやってもらえますと。 version: 0.2 phases: install: commands: - echo install is nothing... - AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) pre_build: commands: - echo Logging in to Amazon ECR... - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com - echo ${DOCKER_HUB_PASSWORD} | docker login -u ${DOCKER_HUB_ID} --password-stdin build: commands: - echo build docker image - docker build -t $CONTAINER_IMAGE . - docker tag $CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG post_build: commands: - echo todo is nothing... - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG