20191020のAWSに関する記事は13件です。

投稿日：2019-10-20T23:43:54+09:00

AWS Toolkit for Visual Studio Codeを使ってみた（C#編）

AWS Toolkit for Visual Studio Codeとは

AWS Toolkit for Visual Studio CodeはAWSがオープンソースで開発を行っているVisual Studio Code（以下VS Code）用のプラグインで、ソースコードはGitHubのaws/aws-toolkit-vscode で公開され開発が進められています。ライセンスは Apache License 2.0で、2019/10/20 時点の最新バージョンは1.1.0です。

AWS Toolkit for Visual Studio Codeの便利な機能

AWS Toolkit for Visual Studio Codeは、VS Codeのプラグインとして下記の便利な機能を提供します。

AWS Serverless Application Model (以下 SAM) を利用したサーバーレスアプリケーションの開発

AWS Lambdaの開発言語として、Node.js、Python、.NET Coreに対応

SAMテンプレートを含むAWS Lambdaファンクションプロジェクトの生成

ユニットテスト用コードの提供

VS Code内でローカル実行やデバッグ実行

VS Code内からSAMテンプレートによるAWSへのデプロイ

利用するための準備

前提条件

AWS Toolkit for Visual Studio Codeをインストールするために必要な前提条件は以下の通りです。

アマゾンウェブサービスのアカウント

サポートされている以下のいずれかのオペレーティングシステム

Windows

Linux

macOS

使用する言語のSDK

.NET Core SDK

Node.js SDK

Python SDK

Visual Studio Code バージョン 1.31.1 以降

また使用する言語に応じて下記のVS Codeプラグインをインストールします。

C# for Visual Studio Code (powered by OmniSharp)

Python extension for Visual Studio Code

AWSサーバーレスアプリケーション開発を行うには以下もインストールします。

AWS SAM CLI（インストールの詳細はこちらを参照）

Docker

筆者は下記の環境で動作を確認しました。

macOS Mojave バージョン 10.14.6

Visual Studio Code バージョン 1.39.2

AWS Toolkit for Visual Studio バージョン 1.1.0

C# for Visual Studio Code (powered by OmniSharp) 1.21.5

.NET Core 3.0.100

aws-cli/1.16.156 Python/3.6.1 Darwin/18.7.0 botocore/1.12.146

SAM CLI, version 0.22.0

Docker version 19.03.2, build 6a30dfc

AWS Toolkit for Visual Studio Codeのインストール

インストールは、シンプルにプラグインをインストールするだけです。

AWSで利用するプロファイルの設定

AWS Toolkit for Visual Studio Codeをインストールしたら、AWSのリソースにアクセスするために認証情報の設定を行います。コマンドパレットから [AWS: Create Credentials Profile]を選択します。

初期プロファイル名、利用するIAM Userの認証情報（アクセスキーIDとシークレットアクセスキー）を入力します。すでに設定されている場合は、~/.aws/credentialsファイルと ~/.aws/configファイルが開きますので、内容を確認します。アクセスキーIDとシークレットアクセスキーの取得の方法は、AWSアクセスキーの取得を参照してください。

AWS Toolkit for Visual Studio Codeの利用

AWS Toolkit for Visual Studio Codeのインストールとプロファイルの設定が完了したら、サーバーレスアプリケーションを開始することができます。

AWSサーバーレスアプリケーションの作成

サーバーレスアプリケーションの開発を始めるために、コマンドパレットから[AWS: Create New SAM Application]を選択します。

作成するサーバーレスアプリケーションの言語を選択します。今回はC#編ということで、dotnetcore2.1を選択します。

ワークスペースのフォルダを選択します。

アプリケーション名を入力します。

サーバーレスアプリケーションプロジェクトが作成され、template.ymlが表示されます。Amazon API Gatewayから呼び出されるAWS LambdaをAWS上に生成するSAMテンプレートが作成されていることがわかります。

ローカル環境でデバッグモードの実行

サーバーレスアプリケーションプロジェクトには、AWS Lambdaファンクションのサンプルコードが予め作成されています。srcフォルダ内のFunction.csを開きます。

左側のアクティビティーバーからAWSアイコンをクリックするとCodeLensが表示されます。デバッグ実行で実行を中断したい行番号の左側をクリックしてブレークポイントを設定します。AWS LambdaファンクションのエントリポイントであるFunctionFunctionHandlerメソッドのCodeLensで[Debug Loccaly]をクリックしてデバッグ実行を開始します。

デバッグツールバーとデバッグコンソールが表示され、.NET Coreアプリケーションがデバッグモードで実行開始されます。

デバッグツールバーの続行（F5）をクリックするとブレイクポイントを設定した箇所で実行が停止することを確認できます。またローカル変数の値が確認できることもわかります。

API Gatewayイベントソースリクエストからの情報の受け取り

Amazon API GatewayをイベントソースとするAWS Lambdaファンクションでイベントソースからの値を受け取るためにAWS Lambda for .NET Coreでは、Amazon.Lambda.APIGatewayEvents.APIGatewayProxyRequestクラスを提供しています。このクラスはパブリックプロパティを集めただけのクラスですが、AWS API Gatewayから渡されるJSONのメンバーの値が自動的にこのクラスのインスタンスにセットされて渡されるようになっています。この動作をデバッグモードの実行でエミュレートするための機能が提供されています。

CodeLensの[Configure]をクリックすると.aws/templates.jsonが開きます。

このevnetプロパティに値をセットするとデバッグ実行にその値を受け取ることができます。サーバーレスアプリケーションプロジェクト内の[アプリケーション]/eents/event.jsonにAWS API Gatewayから渡されるjsonのサンプルがあるので、これをコピーして試してみます。

再度、CodeLensの[Debug Locally]をクリックしてデバッグモードで実行して見るとAPIGatewayProxyRequestクラスのインスタンスであるapigProxyEventに値がセットされて渡されていることが、変数ウィンドウの値で確認できます。

AWSへのデプロイ

AWS Toolkit for Visual Studio Codeが提供する機能を利用して、VS CodeからサーバーレスアプリケーションをAWSへデプロイすることができます。デプロイする前に、あらかじめAmazon S3にデプロイ用のバケットを作成しておきます。
VS Codeのコマンドパレットから[AWS: Deploy SAM Application]を選択します。

SAMテンプレートを選択します。

次にデプロイするリージョンを選択します。

あらかじめ作成しておいたAmazon S3のバケット名を入力します。バケットは1つ前で選択したリージョンに作成している必要があります。

デプロイスタックのための名前を入力します。

以上の手順でVS Codeからサーバーレスアプリケーションをデプロイすることができます。

最後に

AWS Toolkit for Visual Studio Codeを利用することで使い慣れたVS Codeを使用してAWS Lambdaの開発を効率よく行うことができます。今回はC#（.NET Core）で開発を行う例を紹介しましたが、Node.jsやPythonでも同様に利用することができます。この投稿が、VS Codeでサーバーレスアプリケーション開発したいと考えている開発者の方の参考になれば幸いです。

免責

本投稿は、個人の意見で、所属する企業や団体は関係ありません。
また掲載しているサンプルプログラム等の動作に関しても一切保証しておりません。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T22:59:37+09:00

Amazon EKSのALB Ingress Controllerをデプロイする

EKSのIngressチュートリアルをそのままやります

ポリシードキュメントをダウンロード

curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/iam-policy.json

ポリシー作成

aws iam create-policy \
--policy-name ALBIngressControllerIAMPolicy \
--policy-document file://iam-policy.json

ワーカーノード用のIAMポリシーを作成

kubectl -n kube-system describe configmap aws-auth

出力結果

Name:         aws-auth
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
mapRoles:
----
- groups:
  - system:bootstrappers
  - system:nodes
  rolearn: arn:aws:iam::241161305159:role/eksctl-aaa-nodegroup-standard-wor-NodeInstanceRole-16F3YCW1WRZHL
  username: system:node:{{EC2PrivateDNSName}}

mapUsers:
----
[]

Events:  <none>

ポリシーをアタッチ

aws iam attach-role-policy \
--policy-arn arn:aws:iam::241161305159:policy/ALBIngressControllerIAMPolicy \
--role-name eksctl-aaa-nodegroup-standard-wor-NodeInstanceRole-16F3YCW1WRZHL

ALB Ingress Controllerで使用するサービスアカウント、クラスタロールなどを作成

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/rbac-role.yaml

出力結果

ocs/examples/rbac-role.yaml
clusterrole.rbac.authorization.k8s.io/alb-ingress-controller created
clusterrolebinding.rbac.authorization.k8s.io/alb-ingress-controller created
serviceaccount/alb-ingress-controller created

ALB Ingress Controllerのデプロイ

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/alb-ingress-controller.yaml

出力結果

ocs/examples/alb-ingress-controller.yaml
deployment.apps/alb-ingress-controller created

マニュフェスト編集

kubectl edit deployment.apps/alb-ingress-controller -n kube-system

以下を編集

    spec:
      containers:
      - args:
        - --ingress-class=alb
        - --cluster-name=aaa
        - --aws-vpc-id=vpc-0fd48cbe5ca3fc533
        - --aws-region=us-east-2

サンプルアプリケーションデプロイ

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-deployment.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-service.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-ingress.yaml

デプロイ確認

kubectl get ingress/2048-ingress -n 2048-game

出力結果

NAME           HOSTS   ADDRESS                                                                 PORTS   AGE
2048-ingress   *       f007732d-2048game-2048ingr-6fa0-419251603.us-east-2.elb.amazonaws.com   80      117s

アプリケーションの画面

アプリケーション削除

kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-ingress.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-service.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-deployment.yaml
kubectl delete -f https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-ingress-controller/v1.1.2/docs/examples/2048/2048-namespace.yaml

感想

むずい。わからない・・

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T20:19:44+09:00

AWS SQS の可視性タイムアウトとは？何故そんなものがあるのだろうか？を少しだけ考えてみる。( #AWS )

可視性タイムアウトがなかったらどうなるか。

AWS がキューからWorkerにメッセージを渡した瞬間に、メッセージを物理削除してしまったら、ジョブ処理が失敗した時に、復帰できないだろう。なぜなら物理削除されているので。

AWS がキューからWorkerにメッセージ渡した後mお、メッセージを残したままだと、他のWorkerや他のプロセスが、処理が成功する前、あるいは失敗する前に、同じメッセージを受け取ってしまうかもしれない。これでは重複処理が起こるのではないだろうか。

つまり、AWSはメッセージを一定時間論理削除して、ロックしておき、他のプロセスからは見えない状態にしておいて、重複処理されないように守っておく必要がある。これが可視性タイムアウトという分かりにくい名前じゃないだろうか。あーもう単にメッセージロックとかでも良いのでは？

すなわち、たとえば1分かかる処理がある場合、可視性タイムアウトを30秒にしてしまうと、処理が成功する前にロックが外れ、他のプロセスがメッセージを処理してしまう可能性がある。なので可視性タイムアウトの設定は、処理にかかるであろう時間よりも長めに設定しておく必要がある。

AWS SQSが一定期間、メッセージを論理削除して、まるで物理削除されているかのように扱う振る舞いが可視性タイムアウトの仕組みではないか。

Workerは処理が成功したタイミングや処理を諦めたタイミングで、AWS SQSにメッセージを送信して、メッセージ自体を削除する必要がある。これにも可視性タイムアウトの仕組みが関係している気がするが、うまく言語化できるまでは至っていない。

参考

引用の通りですが、SQS には可視性タイムアウトという設定値があって、Shoryuken の worker が SQS から>メッセージを受け取ると、SQS 側はメッセージを一定時間、論理削除します。
worker はジョブが完了すると SQS 側にメッセージの削除要求を投げて、論理削除されていたメッセージを物理削除します。
もし、 worker 側で処理に失敗、または可視性タイムアウトの設定時間を経過しても処理が終わらなかった場合、SQS 側で論理削除を解除して、次のリクエストでメッセージを再配信します。
この仕組みがあるため、 Shoryuken 側でリトライを設定していなくとも、失敗した処理は再度実行されるようになります。
万が一 worker のプロセスが死んでしまっても、 SQS 上でメッセージはちゃんと生きている訳です。

Shoryuken を導入しようとして諦めた話 - Qiita

Original by Github issue

https://github.com/YumaInaura/YumaInaura/issues/2613

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T18:59:28+09:00

CodeBuild の buildspec.yml で `YAML_FILE_ERROR Message: did not find expected comment or line break` が発生

現象

buildspec.yml で CodeBuild を動かすと、以下エラーが発生してビルドがストップする。
[Container] 2019/10/16 11:28:42 Phase complete: DOWNLOAD_SOURCE State: FAILED 
[Container] 2019/10/16 11:28:42 Phase context status code: YAML_FILE_ERROR Message: did not find expected comment or line break at line 20
環境

buildspec.yml の version: 0.2

原因

エラーが示した line 20 は以下の $DRYRUN ... の行。
  build:
    commands:
      - [[ $DRYRUN != 1 ]] || bash -c "./deploy.sh -e ${BUILD_STAGE} ${MODE}"
当該行は、そもそも YAML の構文に従っていなかった。具体的には論理和 || の部分。
| が複数行を記述するための予約文字になっているため、文字列として認識されない。

同様に && も & がアンカーの予約文字になっている。

対応

ダブルクオートでくくることで構文エラーを回避できる。
      - "[[ $DRYRUN != 1 ]] || bash -c \"./deploy.sh -e ${BUILD_STAGE} ${MODE}\""
参考

http://www.yamllint.com/

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T18:45:59+09:00

CloudFormation で `Security group *** did not stabilize` が出て UPDATE できない

現象

CloudFormation でセキュリティグループを更新しようとすると、15 分ほど進捗がストップした後 did not stabilize エラーが出て更新に失敗する。具体的なエラーメッセージは以下の通り。
2019-10-16 18:10:36 UTC+0900    *** UPDATE_FAILED   Security group SG1 did not stabilize
なお、エラーの前にはセキュリティグループが creating one されようとしている。
2019-10-16 17:55:11 UTC+0900    *** UPDATE_IN_PROGRESS
Requested update requires the creation of a new physical resource; hence creating one.
前提

セキュリティグループ名を変更しようとしている

ここでは例として sg1 から SG1 に変更

原因

CloudFormation のエラーメッセージは不親切なことが多いので、実際にマネジメントコンソール上で手を動かしてエラーを再現させる。
creating one だったので、画面上から新規でセキュリティグループを作成したときに発生したエラーメッセージが以下。

セキュリティグループの作成中にエラーが発生しました。
The security group 'SG1' already exists for VPC 'vpc-xxxxx'

今回行おうとしている更新はセキュリティグループ名の大文字小文字の変更だが、どうやら AWS 上ではグループ名の大文字小文字は区別されないらしい。それによって already exists が生じていた模様。

対応

CloudFormation で、大文字小文字の以外の変更 (sg1 → SG1temp など) をすると更新が成功する。
その後、本来変更したかったグループ名 (SG1) に再度変更することで、期待通りの更新ができる。

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T18:39:04+09:00

2019/8 AWS SysOpsアドミニストレータ（SOA) 合格した時にやったことまとめ

はじめに

2019年8月にAWS SysOpsアドミニストレータ（以下SOA）に合格しました。
SAAに合格してこれからSOA受験を検討している方向けに情報を共有したいと思います。

私は7月下旬に1回受けて落ちてしまいましたが、8月11日に再受験して合格しました。

結論から言うと試験範囲と勉強の対象となるサービスに目星をつけてWhizlabsのPractice Tests2019を2周以上してください

AWS support
AWS shield
config
cloudformation
cloudtrail
cloudwatch
IAM
Organizations
WAF
…とか。

不合格になったのは私の準備不足です。
ちゃんとドキュメントを確認しながら勉強することで不合格から2週間後に合格することができました。

目次
・スケジュール
・教材とツール
・やり方
・余談ーAWS資格本を安く購入する方法ー

スケジュール

7/15〜16 AWS SOAについて情報収集
7/17〜27 WEB問題集・BlackBeltで学習
7/28 AWS SOA受験不合格
7/29〜8/10 WhizlabsのAWS SOAを購入。Practice Tests2019を2周半、AWSのドキュメント
8/11 AWS SOA受験合格

教材とツール

Whizlabs・Blackbelt・AWSの各種サービスのドキュメントがおすすめ

Whizlabs

ここは英語のサイトですが問題が充実していてかつリーズナブルな価格で大変助かりました。読めなければChromeの翻訳を使えば問題なく学習を進めることができます。
Practice Tests2019をとにかくやりましょう。
あとLabsというAWSのチュートリアルもついてくるのでオススメです。
SAPやDEVの教材もあるので頼もしい。
700問とAWSのチュートリアルが使えて$19.95です。

AWS サービス別資料 BlackBeltセミナー


ログ周りについてめちゃくちゃ問われるので、そのあたりのサービスは全部見ておきましょう。

AWS 各種サービスのドキュメント


BlackBeltでは取り上げられない細かい話はやっぱりドキュメントを見るに限ります。
問題を一通りやった後に答え合わせの時などに見ると理解が深まります。

WEB問題集で学習しよう
SOAの問題集もありますが、ちょっと問題がそれほど多くありません。
SAAの勉強時にSOAまで学習できるプランで登録していたら。

Scrapbox

私はメモを全部これで取りました。画像の貼り付けやメモがすごく楽。
昨年までは手書きでやっていたのですが、どうしても書くことそれ事態にとても時間がかかってしまうのと、PCとノートをそれぞれ見ながらやるのに疲れてしまったので、現在はこれだけ使っています。

やり方（最初からこうしておけよかった…）

WhizlabsとAWSドキュメント、BlackBeltをぐるぐるしてください

1〜2日目 SOAについて情報収集と受験予約
書籍やWEBで情報収集します。試験範囲や合格記・不合格記などから情報を集めて、どのくらいで合格できそうか目星をつけてスケジュールに落とします。

3日目〜試験日 Whizlabs・BlackBelt・AWSドキュメント
個人的に問題集はWhizlabsのみでいいような気がしています。英語ではありますが問題が充実していてかつ解説もあり、なにより安価です。
Whizlabsをやりながら、分からないところはドキュメントを見ながらやりましょう。

余談ーAWS資格本を安く購入する方法ー

流れ
フリマで定価より安いAWS資格本購入 → AWS資格合格 → AWS資格本を購入した価格でフリマに出品

資格本の購入は、面倒でなければフリマアプリを推奨します。
なぜなら定価の7~8割程度の価格で売ることができるからです。

またAWS資格本は厚みもそれほど無いので、クッション付きの封筒でも問題なく梱包することができます。

フリマで買ってフリマで売却することで費用を最小限に抑えることができます。なぜならフリマで購入した時についてきた梱包材をそのまま出品する際に流用することができるからです。（もちろん物によりますが）

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T18:39:04+09:00

2019.08 AWS SysOpsアドミニストレータ（SOA) 合格した時にやったことまとめ

はじめに

2019年8月にAWS SysOpsアドミニストレータ（以下SOA）に合格しました。
SAAに合格してこれからSOA受験を検討している方向けに情報を共有したいと思います。

私は7月下旬に1回受けて落ちてしまいましたが、8月11日に再受験して合格しました。

結論から言うと試験範囲と勉強の対象となるサービスに目星をつけてWhizlabsのPractice Tests2019を2周以上してください

AWS support
AWS shield
config
cloudformation
cloudtrail
cloudwatch
IAM
Organizations
WAF
…とか。

不合格になったのは私の準備不足です。
ちゃんとドキュメントを確認しながら勉強することで不合格から2週間後に合格することができました。

目次
・スケジュール
・教材とツール
・やり方
・余談ーAWS資格本を安く購入する方法ー

スケジュール

7/15〜16 AWS SOAについて情報収集
7/17〜27 WEB問題集・BlackBeltで学習
7/28 AWS SOA受験不合格
7/29〜8/10 WhizlabsのAWS SOAを購入。Practice Tests2019を2周半、AWSのドキュメント
8/11 AWS SOA受験合格

教材とツール

Whizlabs・Blackbelt・AWSの各種サービスのドキュメントがおすすめ

Whizlabs

ここは英語のサイトですが問題が充実していてかつリーズナブルな価格で大変助かりました。読めなければChromeの翻訳を使えば問題なく学習を進めることができます。
Practice Tests2019をとにかくやりましょう。
あとLabsというAWSのチュートリアルもついてくるのでオススメです。
SAPやDEVの教材もあるので頼もしい。
700問とAWSのチュートリアルが使えて$19.95です。

AWS サービス別資料 BlackBeltセミナー


ログ周りについてめちゃくちゃ問われるので、そのあたりのサービスは全部見ておきましょう。

AWS 各種サービスのドキュメント


BlackBeltでは取り上げられない細かい話はやっぱりドキュメントを見るに限ります。
問題を一通りやった後に答え合わせの時などに見ると理解が深まります。

WEB問題集で学習しよう
SOAの問題集もありますが、ちょっと問題がそれほど多くありません。
SAAの勉強時にSOAまで学習できるプランで登録していたら。

Scrapbox

私はメモを全部これで取りました。画像の貼り付けやメモがすごく楽。
昨年までは手書きでやっていたのですが、どうしても書くことそれ事態にとても時間がかかってしまうのと、PCとノートをそれぞれ見ながらやるのに疲れてしまったので、現在はこれだけ使っています。

やり方（最初からこうしておけよかった…）

WhizlabsとAWSドキュメント、BlackBeltをぐるぐるしてください

1〜2日目 SOAについて情報収集と受験予約
書籍やWEBで情報収集します。試験範囲や合格記・不合格記などから情報を集めて、どのくらいで合格できそうか目星をつけてスケジュールに落とします。

3日目〜試験日 Whizlabs・BlackBelt・AWSドキュメント
個人的に問題集はWhizlabsのみでいいような気がしています。英語ではありますが問題が充実していてかつ解説もあり、なにより安価です。
Whizlabsをやりながら、分からないところはドキュメントを見ながらやりましょう。

余談ーAWS資格本を安く購入する方法ー

流れ
フリマで定価より安いAWS資格本購入 → AWS資格合格 → AWS資格本を購入した価格でフリマに出品

資格本の購入は、面倒でなければフリマアプリを推奨します。
なぜなら定価の7~8割程度の価格で売ることができるからです。

またAWS資格本は厚みもそれほど無いので、クッション付きの封筒でも問題なく梱包することができます。

フリマで買ってフリマで売却することで費用を最小限に抑えることができます。なぜならフリマで購入した時についてきた梱包材をそのまま出品する際に流用することができるからです。（もちろん物によりますが）

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T16:57:19+09:00

AWS Personalizeについて

1.はじめに

AWSにはフルマネージドなレコメンデーションサービスであるAWS Personalizeが用意されています。開発しているシステムにレコメンドエンジンを導入検討にあたって、どういったものなのか調査を行いましたので、その調査内容を取りまとめてみました。
現時点（2019年10月20日）で構築を実際に行ってはいないのですが、肌感覚的には利用できそうだなという感触です。

2.AWS Personalizeについて

AWS Personalizeを利用するにあたって、いくつかの準備が必要となります。その中で出てくる用語が、正直な話わかりづらいです。利用にあたってこれらの言葉を理解しておかないと挫折すると思いますので、私なりにまとめてみました。

2-1.データセットグループ・データセット・スキーマ

どのようなレコメンドエンジンにおいても、レコメンドを行うためには、その素情報を投入する必要があります。AWS Personalizeでは、素情報の総称をデータデータセットグループといいます。データセットグループは、Interactions、Users、Itemsの３種のデータセットで構成され、それぞれ一つずつスキーマ定義することが可能です。
あえてRDBと対応してみます。

AWS Personalize RDB 備考

データセットグループデータベースいくつも作成可能

データセットテーブル RDBと異なり３つしか作れない

スキーマテーブル定義 RDBと異なり自由度はとても低い
ERも変更不可

レコメンドで利用するアルゴリズム（後述のレシピ）によって、利用するデータセットが異なり、３種類すべてを必ず用意する必要があるわけではありません。ただし、Interactionsはすべてのアルゴリズムで利用するため、用意が必須となります。

それぞれのデータセットのスキーマ定義は以下の通りとなります。

2-1-1.Interactions

ユーザとアイテムを紐づけるデータを格納します。紐づける情報とは、例えば評価情報、参照情報、購入量情報、購入金額情報などが該当します。これらは、すべて利用者の操作にまつわるデータであり、AWS Personalizeではイベントといいます。また、評価、参照、購入などをイベントタイプといいます。Interactionsではこれらイベント情報をすべて格納できるように設計されています。

スキーマ定義は以下の通りです。

項目名型説明必須

USER_ID string ユーザを識別するID 〇

ITEM_ID string アイテムを識別するID 〇

EVENT_TYPE string イベントを識別するID

EVENT_VALUE string イベントの値

TIMESTAMP long イベント発生時間（Unix時間=エポック秒）〇

2-1-2.Users

ユーザの情報を格納します。ユーザの情報とは、性別、年齢、所在都道府県、職業といった情報を指します。レコメンド精度を上げるための情報として利用されます。

スキーマ定義は以下の通りです。

項目名型説明必須

USER_ID string ユーザを識別するID 〇

(自由に定義可能) (自由に定義可能) ユーザ属性情報（メタデータ）１〇

(自由に定義可能) (自由に定義可能) ユーザ属性情報２

(自由に定義可能) (自由に定義可能) ユーザ属性情報３

(自由に定義可能) (自由に定義可能) ユーザ属性情報４

(自由に定義可能) (自由に定義可能) ユーザ属性情報５

※USER_ID以外の項目（メタデータ）については、型にstringを指定する場合はcategoricalrical属性をtrueで定義する必要がある。
※1フィールドに複数の値を持つ場合は、パイプ | で連結する
※コードなどをフィールドで持つ場合は数値ではなく文字列として定義したほうが良いと思われる。例えば性別で0を男、1を女としたい場合においても、文字列として定義をするべき。

2-1-3.Items

アイテムの情報を格納します。アイテムの情報とは、商品のカテゴリ、メーカ名などを指します。Users同様にレコメンド精度を上げつための情報として利用されます。

スキーマ定義は以下の通りです。

項目名型説明必須

ITEM_ID string ユーザを識別するID 〇

(自由に定義可能) (自由に定義可能) アイテム属性情報（メタデータ）１〇

(自由に定義可能) (自由に定義可能) アイテム属性情報２

(自由に定義可能) (自由に定義可能) アイテム属性情報３

(自由に定義可能) (自由に定義可能) アイテム属性情報４

(自由に定義可能) (自由に定義可能) アイテム属性情報５

※ITEM_ID以外の項目（メタデータ）については、型にstringを指定する場合はcategoricalrical属性をtrueで定義する必要がある。
※1フィールドに複数の値を持つ場合は、パイプ | で連結する
※コードなどをフィールドで持つ場合は数値ではなく文字列として定義したほうが良いと思われる。

2-2.レシピ

レコメンドにあたって、いろいろなアルゴリズムが存在します。AWS Personalizeでは、このアルゴリズムのことをレシピといいます。なお、AWS Personalizeでは、３種類のレコメンドが存在しており、それぞれ利用できるレシピが異なります。

2-2-1.USER_PERSONALIZATION（あなたにおすすめの商品）

特定ユーザ向けのアイテムリストをレコメンドします。ユーザIDが引数となります。
利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

HRNN 〇ユーザの嗜好や行動が時間とともに変化することに対応したモデル(Hierarchical recurrent neural network)

HRNN-metadata 〇〇類推に当たってメタデータを用いるモデル

HRNN-coldstart 〇〇新しいアイテムが頻繁に追加される場合で、そういったアイテムをすぐに対象としたい場合

popularity-Count 単純にInteractionsデータの件数で提案する。他のレシピの評価用

2-2-2.RELATED_ITEMS（この商品を購入している人はこちらの商品も購入しています）

特定アイテムに類似するアイテムをレコメンドします。アイテムIDが引数になります。
利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

SIMS Interactionsデータからアイテム間類似度を算出し、渡したアイテムと類似度の高いリストを返却する

2-2-3.PERSONALIZED_RANKING（あなた向けランキング）

渡したアイテムリストを特定ユーザ向けに並び替えします。ユーザIDとアイテムIDのリストが引数となります。
＞利用シーンがあまり思い当たらない・・・。

利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

Personalized-Ranking 渡したアイテムのリストをユーザの嗜好順に並び変えて返却

2-3.ソリューション・ソリューションバージョン

レコメンドをするためには、データセットグループを用いて事前に学習（トレーニング）しておく必要があります。このトレーニングのための定義をソリューションといい、利用するレシピ、利用するデータセットグループ、トレーニング用の各種パラメータ（ハイパーパラメタ、Interactionsデータの中に複数イベントがある場合はどのイベントを利用するか）を指定します。また、作成したソリューションを基に、実際にトレーニングを行いますが、そのトレーニング結果をソリューションバージョンといいます。
注意しなければならないことは、ソリューションバージョンは、データセットグループのデータが更新されたとしても反映はされません。反映するためには改めてソリューションバージョンを作成する必要があります。もし更新を行わないと、新しいユーザやアイテムに対してのレコメンド精度が落ちることになります。

なお、設定するハイパーパラメタによってレコメンド精度に影響します。そのためハイパーパラメタのチューニングが必要です。比較検証をするにあたっては、Popularity-Countレシピの指標との比較をするとよいようです。
（詳しい検証方法についてはEvaluation Solutionsを参照）

2-4.キャンペーン

レコメンドのエンドポイントをキャンペーンといいます。キャンペーンの定義をする際に、利用するソリューションバージョンと最小スループットを指定します。この最小スループットは月額費用と性能のトレードオフとなるため、利用シーンに合わせてチューニングしていく必要があります。（大きく設定すると性能もコストも上がる。逆に小さく設定すると性能もコストも下がる。）

2-5.イベントトラッカー

リアルタイムにInterectionsデータを登録し、レコメンド結果に反映させることができます。データ登録に当たっては、SDK経由（PutEvents）で行います。このデータ登録を行わないと、USER_PERSONALIZATIONのレコメンド結果がずっと同じになってしまいます。（例えば、どの商品情報の画面に遷移しても同じレコメンドをされる・・・。）
商品詳細画面を表示する前にイベントトラッカーに表示しようとしている商品のデータを登録することで、最新のInterections情報でレコメンドすることが可能になります。

3.おわりに

どのサイトにも当たり前のように存在しているレコメンド機能ですが、実際に開発をするとなると大げさな実装をしていく必要があります。ASPサービスを用いて実現することも可能ですが、AWSにてお手軽に実現できるというのはとても魅力的だなと思いました。

参考

【AWS Black Belt Online Seminar】Amazon Personalize
【AWS Black Belt Online Seminar】Amazon Personalize PDF資料
 Amazon Personalizeを導入してわかった12のこと
 Amazon Personalizeでレコメンドしてみる話

AWS Personalize	RDB	備考
データセットグループ	データベース	いくつも作成可能
データセット	テーブル	RDBと異なり３つしか作れない
スキーマ	テーブル定義	RDBと異なり自由度はとても低い ERも変更不可

項目名	型	説明	必須
USER_ID	string	ユーザを識別するID	〇
ITEM_ID	string	アイテムを識別するID	〇
EVENT_TYPE	string	イベントを識別するID
EVENT_VALUE	string	イベントの値
TIMESTAMP	long	イベント発生時間（Unix時間=エポック秒）	〇

項目名	型	説明	必須
USER_ID	string	ユーザを識別するID	〇
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報（メタデータ）１	〇
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報２
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報３
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報４
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報５

項目名	型	説明	必須
ITEM_ID	string	ユーザを識別するID	〇
(自由に定義可能)	(自由に定義可能)	アイテム属性情報（メタデータ）１	〇
(自由に定義可能)	(自由に定義可能)	アイテム属性情報２
(自由に定義可能)	(自由に定義可能)	アイテム属性情報３
(自由に定義可能)	(自由に定義可能)	アイテム属性情報４
(自由に定義可能)	(自由に定義可能)	アイテム属性情報５

レシピ	AutoML対象	Users,Itemsを使用	説明
HRNN	〇		ユーザの嗜好や行動が時間とともに変化することに対応したモデル(Hierarchical recurrent neural network)
HRNN-metadata	〇	〇	類推に当たってメタデータを用いるモデル
HRNN-coldstart	〇	〇	新しいアイテムが頻繁に追加される場合で、そういったアイテムをすぐに対象としたい場合
popularity-Count			単純にInteractionsデータの件数で提案する。他のレシピの評価用

レシピ	AutoML対象	Users,Itemsを使用	説明
SIMS			Interactionsデータからアイテム間類似度を算出し、渡したアイテムと類似度の高いリストを返却する

レシピ	AutoML対象	Users,Itemsを使用	説明
Personalized-Ranking			渡したアイテムのリストをユーザの嗜好順に並び変えて返却

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T16:57:19+09:00

AWSが提供するフルマネージドレコメンドエンジン『AWS Personalize』について

1.はじめに

AWSにはフルマネージドなレコメンデーションサービスであるAWS Personalizeが用意されています。開発しているシステムにレコメンドエンジンを導入検討にあたって、どういったものなのか調査を行いましたので、その調査内容を取りまとめてみました。
現時点（2019年10月20日）で構築を実際に行ってはいないのですが、肌感覚的には利用できそうだなという感触です。

2.AWS Personalizeについて

AWS Personalizeを利用するにあたって、いくつかの準備が必要となります。その中で出てくる用語が、正直な話わかりづらいです。利用にあたってこれらの言葉を理解しておかないと挫折すると思いますので、私なりにまとめてみました。

2-1.データセットグループ・データセット・スキーマ

どのようなレコメンドエンジンにおいても、レコメンドを行うためには、その素情報を投入する必要があります。AWS Personalizeでは、素情報の総称をデータデータセットグループといいます。データセットグループは、Interactions、Users、Itemsの３種のデータセットで構成され、それぞれ一つずつスキーマ定義することが可能です。
あえてRDBと対応してみます。

AWS Personalize RDB 備考

データセットグループデータベースいくつも作成可能

データセットテーブル RDBと異なり３つしか作れない

スキーマテーブル定義 RDBと異なり自由度はとても低い
ERも変更不可

レコメンドで利用するアルゴリズム（後述のレシピ）によって、利用するデータセットが異なり、３種類すべてを必ず用意する必要があるわけではありません。ただし、Interactionsはすべてのアルゴリズムで利用するため、用意が必須となります。

それぞれのデータセットのスキーマ定義は以下の通りとなります。

2-1-1.Interactions

ユーザとアイテムを紐づけるデータを格納します。紐づける情報とは、例えば評価情報、参照情報、購入量情報、購入金額情報などが該当します。これらは、すべて利用者の操作にまつわるデータであり、AWS Personalizeではイベントといいます。また、評価、参照、購入などをイベントタイプといいます。Interactionsではこれらイベント情報をすべて格納できるように設計されています。

スキーマ定義は以下の通りです。

項目名型説明必須

USER_ID string ユーザを識別するID 〇

ITEM_ID string アイテムを識別するID 〇

EVENT_TYPE string イベントを識別するID

EVENT_VALUE string イベントの値

TIMESTAMP long イベント発生時間（Unix時間=エポック秒）〇

2-1-2.Users

ユーザの情報を格納します。ユーザの情報とは、性別、年齢、所在都道府県、職業といった情報を指します。レコメンド精度を上げるための情報として利用されます。

スキーマ定義は以下の通りです。

項目名型説明必須

USER_ID string ユーザを識別するID 〇

(自由に定義可能) (自由に定義可能) ユーザ属性情報（メタデータ）１〇

(自由に定義可能) (自由に定義可能) ユーザ属性情報２

(自由に定義可能) (自由に定義可能) ユーザ属性情報３

(自由に定義可能) (自由に定義可能) ユーザ属性情報４

(自由に定義可能) (自由に定義可能) ユーザ属性情報５

※USER_ID以外の項目（メタデータ）については、型にstringを指定する場合はcategoricalrical属性をtrueで定義する必要がある。
※1フィールドに複数の値を持つ場合は、パイプ | で連結する
※コードなどをフィールドで持つ場合は数値ではなく文字列として定義したほうが良いと思われる。例えば性別で0を男、1を女としたい場合においても、文字列として定義をするべき。

2-1-3.Items

アイテムの情報を格納します。アイテムの情報とは、商品のカテゴリ、メーカ名などを指します。Users同様にレコメンド精度を上げつための情報として利用されます。

スキーマ定義は以下の通りです。

項目名型説明必須

ITEM_ID string ユーザを識別するID 〇

(自由に定義可能) (自由に定義可能) アイテム属性情報（メタデータ）１〇

(自由に定義可能) (自由に定義可能) アイテム属性情報２

(自由に定義可能) (自由に定義可能) アイテム属性情報３

(自由に定義可能) (自由に定義可能) アイテム属性情報４

(自由に定義可能) (自由に定義可能) アイテム属性情報５

※ITEM_ID以外の項目（メタデータ）については、型にstringを指定する場合はcategoricalrical属性をtrueで定義する必要がある。
※1フィールドに複数の値を持つ場合は、パイプ | で連結する
※コードなどをフィールドで持つ場合は数値ではなく文字列として定義したほうが良いと思われる。

2-2.レシピ

レコメンドにあたって、いろいろなアルゴリズムが存在します。AWS Personalizeでは、このアルゴリズムのことをレシピといいます。なお、AWS Personalizeでは、３種類のレコメンドが存在しており、それぞれ利用できるレシピが異なります。

2-2-1.USER_PERSONALIZATION（あなたにおすすめの商品）

特定ユーザ向けのアイテムリストをレコメンドします。ユーザIDが引数となります。
利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

HRNN 〇ユーザの嗜好や行動が時間とともに変化することに対応したモデル(Hierarchical recurrent neural network)

HRNN-metadata 〇〇類推に当たってメタデータを用いるモデル

HRNN-coldstart 〇〇新しいアイテムが頻繁に追加される場合で、そういったアイテムをすぐに対象としたい場合

popularity-Count 単純にInteractionsデータの件数で提案する。他のレシピの評価用

2-2-2.RELATED_ITEMS（この商品を購入している人はこちらの商品も購入しています）

特定アイテムに類似するアイテムをレコメンドします。アイテムIDが引数になります。
利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

SIMS Interactionsデータからアイテム間類似度を算出し、渡したアイテムと類似度の高いリストを返却する

2-2-3.PERSONALIZED_RANKING（あなた向けランキング）

渡したアイテムリストを特定ユーザ向けに並び替えします。ユーザIDとアイテムIDのリストが引数となります。
＞利用シーンがあまり思い当たらない・・・。

利用できるレシピは以下の通りです。

レシピ AutoML対象 Users,Itemsを使用説明

Personalized-Ranking 渡したアイテムのリストをユーザの嗜好順に並び変えて返却

2-3.ソリューション・ソリューションバージョン

レコメンドをするためには、データセットグループを用いて事前に学習（トレーニング）しておく必要があります。このトレーニングのための定義をソリューションといい、利用するレシピ、利用するデータセットグループ、トレーニング用の各種パラメータ（ハイパーパラメタ、Interactionsデータの中に複数イベントがある場合はどのイベントを利用するか）を指定します。また、作成したソリューションを基に、実際にトレーニングを行いますが、そのトレーニング結果をソリューションバージョンといいます。
注意しなければならないことは、ソリューションバージョンは、データセットグループのデータが更新されたとしても反映はされません。反映するためには改めてソリューションバージョンを作成する必要があります。もし更新を行わないと、新しいユーザやアイテムに対してのレコメンド精度が落ちることになります。

なお、設定するハイパーパラメタによってレコメンド精度に影響します。そのためハイパーパラメタのチューニングが必要です。比較検証をするにあたっては、Popularity-Countレシピの指標との比較をするとよいようです。
（詳しい検証方法についてはEvaluation Solutionsを参照）

2-4.キャンペーン

レコメンドのエンドポイントをキャンペーンといいます。キャンペーンの定義をする際に、利用するソリューションバージョンと最小スループットを指定します。この最小スループットは月額費用と性能のトレードオフとなるため、利用シーンに合わせてチューニングしていく必要があります。（大きく設定すると性能もコストも上がる。逆に小さく設定すると性能もコストも下がる。）

2-5.イベントトラッカー

リアルタイムにInterectionsデータを登録し、レコメンド結果に反映させることができます。データ登録に当たっては、SDK経由（PutEvents）で行います。このデータ登録を行わないと、USER_PERSONALIZATIONのレコメンド結果がずっと同じになってしまいます。（例えば、どの商品情報の画面に遷移しても同じレコメンドをされる・・・。）
商品詳細画面を表示する前にイベントトラッカーに表示しようとしている商品のデータを登録することで、最新のInterections情報でレコメンドすることが可能になります。

3.おわりに

どのサイトにも当たり前のように存在しているレコメンド機能ですが、実際に開発をするとなると大げさな実装をしていく必要があります。ASPサービスを用いて実現することも可能ですが、AWSにてお手軽に実現できるというのはとても魅力的だなと思いました。

参考

【AWS Black Belt Online Seminar】Amazon Personalize
【AWS Black Belt Online Seminar】Amazon Personalize PDF資料
 Amazon Personalizeを導入してわかった12のこと
 Amazon Personalizeでレコメンドしてみる話

AWS Personalize	RDB	備考
データセットグループ	データベース	いくつも作成可能
データセット	テーブル	RDBと異なり３つしか作れない
スキーマ	テーブル定義	RDBと異なり自由度はとても低い ERも変更不可

項目名	型	説明	必須
USER_ID	string	ユーザを識別するID	〇
ITEM_ID	string	アイテムを識別するID	〇
EVENT_TYPE	string	イベントを識別するID
EVENT_VALUE	string	イベントの値
TIMESTAMP	long	イベント発生時間（Unix時間=エポック秒）	〇

項目名	型	説明	必須
USER_ID	string	ユーザを識別するID	〇
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報（メタデータ）１	〇
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報２
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報３
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報４
(自由に定義可能)	(自由に定義可能)	ユーザ属性情報５

項目名	型	説明	必須
ITEM_ID	string	ユーザを識別するID	〇
(自由に定義可能)	(自由に定義可能)	アイテム属性情報（メタデータ）１	〇
(自由に定義可能)	(自由に定義可能)	アイテム属性情報２
(自由に定義可能)	(自由に定義可能)	アイテム属性情報３
(自由に定義可能)	(自由に定義可能)	アイテム属性情報４
(自由に定義可能)	(自由に定義可能)	アイテム属性情報５

レシピ	AutoML対象	Users,Itemsを使用	説明
HRNN	〇		ユーザの嗜好や行動が時間とともに変化することに対応したモデル(Hierarchical recurrent neural network)
HRNN-metadata	〇	〇	類推に当たってメタデータを用いるモデル
HRNN-coldstart	〇	〇	新しいアイテムが頻繁に追加される場合で、そういったアイテムをすぐに対象としたい場合
popularity-Count			単純にInteractionsデータの件数で提案する。他のレシピの評価用

レシピ	AutoML対象	Users,Itemsを使用	説明
SIMS			Interactionsデータからアイテム間類似度を算出し、渡したアイテムと類似度の高いリストを返却する

レシピ	AutoML対象	Users,Itemsを使用	説明
Personalized-Ranking			渡したアイテムのリストをユーザの嗜好順に並び変えて返却

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T16:50:34+09:00

【AWS メモ⑦】リバースプロキシの設定(Squid3.5)

Squid3.5でリバースプロキシ設定を仕事で使う機会があったので備忘録的なものを残しておく。

前提

以下の環境で実行。

サブネット

サブネット名ルートテーブル設定

public-subnet ・local

private-web-subnet ・local
・インターネットゲートウェイ

セキュリティグループ

セキュリティグループ名設定

public-sg ・社内グローバルIPアドレスからのアクセスを許可(ポート22)
・HTTPアクセスを許可(ポート80)

private-web-sg ・public-sgからのアクセスのみ許可(ポート80)

EC2

ホスト名 OS セキュリティグループ

proxy-server Amazon Linux 2 public-sg

private-web-server Amazon Linux 2 private-sg

プライベートサブネット内のWebサーバへのアクセスはパブリックサブネットに構築したプロキシサーバを経由して行う。

プロキシサーバーの設定

proxy-server にSquid3.5をインストールする。
$ sudo yum install squid -y
自動起動を有効にする。
$ sudo systemctl enable squid
Squidの設定ファイルを開く。
$ sudo vi /etc/squid/squid.conf
設定ファイルに、以下の設定を追加する。
ここでは、 HTTPアクセスを全て許可する。
http_access allow all
ポート番号の指定（デフォルトでは3128）箇所をコメントアウトする。
転送先の設定を追加する。
# Squid normally listens to port 3128
#http_port 3128  ← コメントアウト

# 以下の形式で転送先の設定を追加
# http_port <SquidサーバのプライベートIPアドレス>:<ポート番号> accel defaultsite=<WebサーバのプライベートIPアドレス>
http_port xxx.xxx.xxx.xxx:80 accel defaultsite=xxx.xxx.xxx.xxx
キャッシュ設定を追加する。
# WebサーバのプライベートIPアドレス を設定
cache_peer xxx.xxx.xx.xxx parent 80 0 no-query originserver

# メモリキャッシュサイズを設定
cache_mem 256 MB
最後に、ホスト名定義を追加する。
# WebサーバのプライベートIPアドレス を設定
visible_hostname xxx.xxx.xxx.xxx
設定完了後、サービスを再起動する。
$ sudo service squid restart
動作確認（Webサーバなし）

Webサーバを起動せずにSquidのサーバが正常に動作しているかを確認する。

ブラウザにプロキシサーバのIPアドレスを入力して、アクセスする。
以下の画面が表示されていればとりあえずアクセスは完了している。ただし、吹き出し箇所にvisible_hostnameに設定したIPアドレスが表示されてしまう。

なるべくブラウザ側からサーバの情報は確認できないようにした方が良いので、先ほどの設定を見直す。

Squidの設定ファイルを開く。
$ sudo vi /etc/squid/squid.conf
こざかしいがunknownと表示されるように変更する。
# WebサーバのプライベートIPアドレス を設定
visible_hostname unknown
設定完了後、サービスを再起動する。
$ sudo service squid restart
今度は、unknownと表示されるようになる。

次は、バージョンも非表示にする。

Squidの設定ファイルを開く。
$ sudo vi /etc/squid/squid.conf
以下の設定を追加して、バージョンを非表示にする。
httpd_suppress_version_string on
設定完了後、サービスを再起動する。
$ sudo service squid restart
今度は、バージョンが表示されなくなる。

Squid側の設定は以上で終了。

Webサーバ側の設定

今回は、Apacheサーバを起動してアクセスできることを確認するので、Apacheの起動だけ行う。
$ sudo systemctl start httpd
プロキシサーバ経由でWebサーバのアクセス

ブラウザにプロキシサーバのIPアドレスを入力して、アクセスする。
Apacheのテストページが表示されることを確認する。

おまけ：複数のWebサーバへ処理を割り振る場合の設定

例えば、WebサーバA~Cまである場合は以下のように設定を行う。
ラウンドロビンで負荷分散されるようになる。
# http_port <SquidサーバのプライベートIPアドレス>:<ポート番号> accel defaultsite=<WebサーバAのプライベートIPアドレス>
http_port xxx.xxx.xxx.xxx:80 accel defaultsite=xxx.xxx.xxx.xxx

cache_peer <WebサーバAのプライベートIPアドレス> parent 80 0 no-query originserver round-robin
cache_peer <WebサーバBのプライベートIPアドレス> parent 80 0 no-query originserver round-robin
cache_peer <WebサーバCのプライベートIPアドレス> parent 80 0 no-query originserver round-robin
補足

AWSでリバースプロキシを使用する場合、ELBを使用することが多いが、ELBでは5分間隔でのログ取得となっている。
そのため、リアルタイムのログ監視を行いたい場合はプロキシサーバを自前で用意する場合がある。
もし構築する必要がある場合は、今回使用したようなEC2での運用だと単一障害点になるので、ECSを使用すると良いかもしれない。

サブネット名	ルートテーブル設定
public-subnet	・local
private-web-subnet	・local ・インターネットゲートウェイ

セキュリティグループ名	設定
public-sg	・社内グローバルIPアドレスからのアクセスを許可(ポート22) ・HTTPアクセスを許可(ポート80)
private-web-sg	・public-sgからのアクセスのみ許可(ポート80)

ホスト名	OS	セキュリティグループ
proxy-server	Amazon Linux 2	public-sg
private-web-server	Amazon Linux 2	private-sg

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T14:08:37+09:00

AWS Cloud9 で作成した AWS Lambda 関数で kintone Webhook 通知を受信する

AWS Cloud9 で作成した Lambda 関数に、kintone の Webhook 通知を投げて結果を確認してみます。

AWS Cloud9 であらかじめ作成した Lambda関数(blue print)を元に進めます。
ここまでの作業は AWS Cloud9 で AWS Lambda を開発する環境を構築してみるを参考にしてください。

前提条件

Cloud9 環境作成済み

CodeCommit 環境作成済み

API Gateway 環境作成済み

AWS Lambda 環境作成済み

kintone Webhook の設定

作成した blue print そのままのコードの Lambda関数に、Webhook通知を投げてみます。

Webhook 通知の設定

アプリの設定を変更する → 設定タブ → Webhook を選択します。

Webhookの設定値を入力します。
Webhook URL には、作成した Lambda関数に紐付けた API Gateway のエンドポイントを入力します。

ステータスの更新通知を有効にしたら、プロセス管理を有効化しておきます。

アプリを更新します。

Webhook 通知のテスト

レコードの追加、編集、削除、コメントの書き込み、ステータスの更新を順番にテストしてみます。

レコードの追加

アプリにてレコードを新規作成して保存します。

kintone Webhookログの確認

アプリの設定→Webhook→Webhookログでログを確認します。

監査ログも確認します。

Cloud Watch ログの確認

AWS Cloud Watch ログを確認します。

kintone のレコードが確認できます。

Lambda関数
index.js
"use strict";
let sc; // Status code
let result = "";
exports.handler = function(event, context, callback) {
    console.log(event);
    const kintonePost = JSON.parse(event.body);
    console.log(kintonePost);
    sc = 200;
    result = "kintone POST success!";
    const response = {
      statusCode: sc,
      headers: { "Content-type": "application/json" },
      body: JSON.stringify( result )
    };
   callback(null, response);
};
kintone Webhook で受信した POST リクエストをそのままログに出力しています。
callback で kintone にステータスコードを返しています。

API Gateway で取得した kintone の Webhook リクエストは、ハンドラ関数の event 変数に入ってきます。

kintone record の中身は event.body に入っているので、JSON.parse して JavaScript のオブジェクトに変換しています。

レコードの中身にアクセスするには、例えば [$id] の場合は下記になります。

JSON.parse(record.body).kintonePost.record['$id'].value

関連リンク

AWS 関連

AWS Cloud9 Integrated Development Environment (IDE) で AWS Lambda 関数を操作する

AWS CloudFormation

AWS Cloud9上で作成したLambda関数で環境変数を利用する

環境変数を使用する Lambda 関数を呼び出す

Node.js 関連

Request - Simplified HTTP client

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T12:17:05+09:00

差分バックアップと増分バックアップの違い

AWSのEBSのスナップショットは増分バックアップであり、差分バックアップではないらしい。
で、この２つの違いは何？、と思ったのでメモ。

共通点

初回にフルバックアップをとる

増分バックアップ

２回目以降は前回からの増分のみをバックアップする。

１回あたりのバックアップ容量は少なくてすむが、復元時の処理が煩雑。

1回目 / [100GB]
2回目 / [100GB] + [10GB]
3回目 / [110GB] + [15GB]

差分バックアップ

2回目以降は初回からの増分のみをバックアップする。

バックアップ処理が簡易だが、世代が多いと容量がかさむ

1回目 / [100GB]
2回目 / [100GB] + [10GB]
3回目 / [100GB] + [10GB] + [15GB]

　 Tweet
Qiitaで続きを読む

投稿日：2019-10-20T00:10:36+09:00

AWSのLambdaLayersでpandasを使おうとしたらトラブった話

記事概要

トラブルの内容

AWS Layersでpandasを使えるようにしたかった

numpyのインポートでエラー

解決策

AmazonLinux2ではなくてAmazonLinuxを使う

Pythonのバージョンを合わせる

最近コンテナで開発環境を用意していたから、Pythonのバージョンに全然気を使っていなかった。

AWS Layersとは

これまでLambdaでnumpyやpandasを使おうとすると
- AmazonLinuxインスタンスを用意
- 利用するモジュールをpip install
- Lambda関数の本体スクリプトと共にzipファイルにまとめる
- AWSにアップロードする

デプロイパッケージを作成する必要があった。おまけにコンソールからスクリプトが見えないし、メンテナンスやデバッグもかなりめんどくさい。

それを解決するのがLayers機能。

AWS Lambda レイヤー - AWS Lambda

出てきたエラー

エラーメッセージは下記の通り。なんかnumpyがうまく動いてないらしい。
START RequestId: 7cf66e49-c9f4-48d3-8212-3b9279a8ee02 Version: $LATEST
Unable to import module 'lambda_function': 

IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!

Importing the multiarray numpy extension module failed.  Most
likely you are trying to import a failed build of numpy.
Here is how to proceed:
- If you're working with a numpy git repository, try `git clean -xdf`
  (removes all files not under version control) and rebuild numpy.
- If you are simply trying to use the numpy version that you have installed:
  your installation is broken - please reinstall numpy.
- If you have already reinstalled and that did not fix the problem, then:
  1. Check that you are using the Python you expect (you're using /var/lang/bin/python3.6),
     and that you have no directories in your PATH or PYTHONPATH that can
     interfere with the Python and numpy versions you're trying to use.
  2. If (1) looks fine, you can open a new issue at
     https://github.com/numpy/numpy/issues.  Please include details on:
     - how you installed Python
     - how you installed numpy
     - your operating system
     - whether or not you have multiple versions of Python installed
     - if you built from source, your compiler versions and ideally a build log

     Note: this error has many possible causes, so please don't comment on
     an existing issue about this - open a new one instead.

Original error was: /opt/python/numpy/core/_multiarray_umath.so: undefined symbol: _Py_ZeroStruct


END RequestId: 7cf66e49-c9f4-48d3-8212-3b9279a8ee02
REPORT RequestId: 7cf66e49-c9f4-48d3-8212-3b9279a8ee02  Duration: 0.51 ms   Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 73 MB  Init Duration: 423.73 ms    
対処① AmazonLinux2ではなくてAmazonLinuxを使う

ここを見るとLambda関数はAmazonLinuxで動いているらしい。なのでzipファイルはAmazonLinuxのインスタンス上で用意しないといけない。

対処② Pythonのバージョンをlambda関数のランタイムと合わせる

最近はSageMakerで全て済ましてしまうのでうっかりしていたが、Linuxはpython2.7がデフォルトだ。
コンテナで環境構築すると最初からPython3になっていることが多いからね。

pyenvを導入してLambda関数側のpythonのバージョン(3.6)と合わせることで解決

　 Tweet
Qiitaで続きを読む

20191020のAWSに関する記事は13件です。

AWS Toolkit for Visual Studio Codeを使ってみた（C#編）

AWS Toolkit for Visual Studio Codeとは

AWS Toolkit for Visual Studio Codeの便利な機能

利用するための準備

前提条件

AWS Toolkit for Visual Studio Codeのインストール

AWSで利用するプロファイルの設定

AWS Toolkit for Visual Studio Codeの利用

AWSサーバーレスアプリケーションの作成

ローカル環境でデバッグモードの実行

API Gatewayイベントソースリクエストからの情報の受け取り

AWSへのデプロイ

最後に

免責

Amazon EKSのALB Ingress Controllerをデプロイする

ポリシードキュメントをダウンロード

ポリシー作成

ワーカーノード用のIAMポリシーを作成

ポリシーをアタッチ

ALB Ingress Controllerで使用するサービスアカウント、クラスタロールなどを作成

ALB Ingress Controllerのデプロイ

マニュフェスト編集

サンプルアプリケーションデプロイ

デプロイ確認

アプリケーション削除

感想

AWS SQS の可視性タイムアウトとは？何故そんなものがあるのだろうか？ を少しだけ考えてみる。( #AWS )

可視性タイムアウトがなかったらどうなるか。

参考

Original by Github issue

CodeBuild の buildspec.yml で `YAML_FILE_ERROR Message: did not find expected comment or line break` が発生

現象

環境

原因

対応

参考

CloudFormation で `Security group *** did not stabilize` が出て UPDATE できない

現象

前提

原因

対応

2019/8 AWS SysOpsアドミニストレータ（SOA) 合格した時にやったことまとめ

はじめに

スケジュール

教材とツール

やり方（最初からこうしておけよかった…）

余談 ーAWS資格本を安く購入する方法ー

2019.08 AWS SysOpsアドミニストレータ（SOA) 合格した時にやったことまとめ

はじめに

スケジュール

教材とツール

やり方（最初からこうしておけよかった…）

余談 ーAWS資格本を安く購入する方法ー

AWS Personalizeについて

1.はじめに

2.AWS Personalizeについて

2-1.データセットグループ・データセット・スキーマ

2-1-1.Interactions

2-1-2.Users

2-1-3.Items

2-2.レシピ

2-2-1.USER_PERSONALIZATION（あなたにおすすめの商品）

2-2-2.RELATED_ITEMS（この商品を購入している人はこちらの商品も購入しています）

2-2-3.PERSONALIZED_RANKING（あなた向けランキング）

2-3.ソリューション・ソリューションバージョン

2-4.キャンペーン

2-5.イベントトラッカー

3.おわりに

参考

AWSが提供するフルマネージドレコメンドエンジン『AWS Personalize』について

1.はじめに

2.AWS Personalizeについて

2-1.データセットグループ・データセット・スキーマ

2-1-1.Interactions

2-1-2.Users

2-1-3.Items

2-2.レシピ

2-2-1.USER_PERSONALIZATION（あなたにおすすめの商品）

2-2-2.RELATED_ITEMS（この商品を購入している人はこちらの商品も購入しています）

AWS SQS の可視性タイムアウトとは？何故そんなものがあるのだろうか？を少しだけ考えてみる。( #AWS )

余談ーAWS資格本を安く購入する方法ー

余談ーAWS資格本を安く購入する方法ー

AWS Cloud9 で作成した AWS Lambda 関数で kintone Webhook 通知を受信する