概要

Serverless Framework を試すためにすることをまとめました。

はじめに

Serverless Framework を試すのに 3 点候補あげておきますが、この記事では「AWS Lambda」を扱います。

• Amazon Web Services
  • AWS Lambda
• Google Cloud Platform
  • Google Cloud Functions
• Microsoft Azure
  • Azure Functions

前提条件

• AWS アカウント作成済み
• AWS マネジメントコンソールに入れること
• IAM でアクセスキーを作成済み
• IAM で作成したアクセスキーを確認できる状態にすること
• Homebrew をインストール済み
• Node.js をインストール済み
• npm -v で問題なくバージョンが表示されること

やることリスト

• awscli のインストール
• AWS CLI の設定
• Serverless Framework のインストール

awscli のインストール

AWS の機能をターミナル上から使えるようにするためのもの。

brew install awscli

AWS CLI の設定

• accountName は任意の名前
• --profile はどのアカウントを設定するのかを明示するもの
  • (複数の AWS アカウントを扱えるようにきちんと切り分ける)

aws configure --profile accountName

解説

IAM で作成したアクセスキーを見ながら入力する。

$ aws configure --profile accountName
AWS Access Key ID [None]: ここには Access key ID
AWS Secret Access Key [None]: ここには Secret access key
Default region name [None]: ap-northeast-1
Default output format [None]: json

• Default region name について気になる人はリージョンとアベイラビリティーゾーン
• Default output format はいくつか種類がありますが気になる人は出力形式について

Serverless Framework のインストール

npm install -g serverless

Serverless Framework で雛形を作成

• --template は他にも指定できるものがあり、 serverless create --help で確認できます
• --path で指定した名前のディレクトリが作成される

serverless create --template aws-nodejs --path quick-start

実行結果

"
 _______                             __
|   _   .-----.----.--.--.-----.----|  .-----.-----.-----.
|   |___|  -__|   _|  |  |  -__|   _|  |  -__|__ --|__ --|
|____   |_____|__|  \___/|_____|__| |__|_____|_____|_____|
|   |   |             The Serverless Application Framework
|       |                           serverless.com, v1.36.3
 -------'

Serverless: Successfully generated boilerplate for template: "aws-nodejs"

作業ディレクトリに移動

cd quick-start

早速 AWS に デプロイする

• --verbose は情報を詳細に出してくれる
• --aws-profile は aws configure --profile した時の名前を入れる
• --region は東京(ap-northeast-1)を指定

serverless deploy --verbose --aws-profile accountName --region ap-northeast-1

実行結果

Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...

~~
~~

Serverless: Stack update finished...

Service Information
service: quick-start
stage: dev
region: ap-northeast-1
stack: quick-start-dev
api keys:
  None
endpoints:
  None
functions:
  hello: quick-start-dev-hello
layers:
  None

Stack Outputs
HelloLambdaFunctionQualifiedArn: ...
ServerlessDeploymentBucketName: ...

デプロイしたやつを AWS 上で確認する

AWS コンソールにログイン後

• 東京リージョンになっていることを確認
• サービス検索から「Lambda」を検索する

Lambda の画面で

• 左側に見える「関数」をクリック
• 今回デプロイしたもの「quick-start-dev-hello」をクリック

quick-start-dev-hello の画面

この画面を活用する方法は別記事で説明します。
デプロイしたものは、この様に確認できます。

デプロイしたやつを実行する

• --function は実行したい関数の名前
• --log は実行した時のメモリ使用量や実⾏時間、課⾦対象時間などを表示
• --aws-profile 、 --region は前回の通り

serverless invoke --function hello --log --aws-profile accountName --region ap-northeast-1

実行結果

{
    "statusCode": 200,
    "body": "{\"message\":\"Go Serverless v1.0! Your function executed successfully!\",\"input\":{}}"
}

最後に

今回試しに動作させたものを消す

不要だったら捨てる。
必要ならまた serverless deploy しましょう。

serverless remove --aws-profile accountName --region ap-northeast-1

次回

Serverless Framework で API サーバーを構築するやつをやっていきましょう。

1. はじめに

ここでは、GuradDutyの有効化や基本的な機能を触ってみた際の様子をご紹介します。

2. GuardDutyの有効化

実はこれ、「GuardDutyの有効化」ってボタンを押すだけなんですよね。すごい。
簡単すぎてスクショ取り忘れました。。。

3. GuardDutyのコンソール

コンソールの主な画面を見ていきます。

結果画面

出力されているログはサンプルです

設定画面

GuardDutyの有効化、無効化などができるようです。

4. GuardDutyの料金（2019年1月現在）

約1ヶ月の無料トライアル期間が設定されているため、ありがたく使用させていただきました。
基本はエンタープライズ向けのサービスだと思いますが、それを考えてもかなりお手軽な料金だと思います。
https://aws.amazon.com/jp/guardduty/pricing/

5. サンプルログの出力

「設定」→「結果サンプルの生成」から、GuardDutyのログのサンプルを出力させられます。

試しに一つ見てみましょう
ログを選択すると、右横のペインから詳細が見られました。
表示方法は画面右上から選べるようです。

Trojan:EC2/PhishingDomainRequest!DNS

この検出結果がどのようなものか知りたい場合は、ユーザーガイドを参照すれば良さそうです。

GuardDuty の Trojan 検索タイプ
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_trojan.html

様々なタイプが紹介されていますね。これ読むのも楽しそうです。

6. CloudWatchへの通知

GuardDutyの「設定」を見ると、次のような項目があります。
Cloud Watch Event(CWE)に通知を飛ばしているようですね。

早速CloudWatchのコンソールで見てみましょう。

イベント→ルール→ルールの作成と進みます。
こんな感じで「GuardDuty」の「GuardDuty Finding」をトリガに、ターゲットとなる動作を実行できるようです。
Lambda関数が実行できるので、かなり自由度が高そうですね。

詳細は割愛しますが、SNSで通知飛ばせるようにしてみました。アイディアが平凡ですみません、、、

7. おわりに

圧倒的な速さでいわばIDSが導入できるのは圧巻でした。ボタン押すだけ？信じられないですね。
CloudWatch Event越しにLambda関数の実行もできるなど、GuradDutyのイベントトリガで様々なタスクが自動化できそうです。

では、GuardDutyのログが出るまで待ちます。

概要

• Cloud9には、ペアプログラミング用にユーザーの共有設定がある。
• 共有設定を、IAMユーザーでなくIAMロールに設定する方法について記載。
• 実際、ここ（Environment と異なるアカウントのユーザーを招待する）に書いてあるままといえば、そのとおり。

方法

方法１. マネージメントコンソールから付与する

• Environment と異なるアカウントのユーザーを招待する
• 注意点は、共有するユーザー（ [Invite Members (メンバーを招待する)] ）には、スイッチロール(STS)時のARNを指定すること
  • 例）arn:aws:sts::[account_id]:assumed-role/[Role名]/[スイッチロールするIAMユーザー名]

方法２.　CLIから付与する

• 上記の手順にはないけど、CLIでも設定できる
  • create-environment-membership
  • New-C9EnvironmentMembership Cmdlet
• このとき、EnvironmentId指定でメンバー追加をしなきゃいけないけど、Listコマンドで取ったとき、Idの情報しか取れんかったので、以下のスクリプトでいい感じに他情報も取って、create-environment-membership実行しました。
• create-environment-membershipの--user-arnももちろん、スイッチロール(STS)時のARNを指定すること

$c9_list = @(Get-C9EnvironmentList)
Write-Output $c9_list

$arrResults = @()
foreach ($c9_id in $c9_list) {
    $c9_data = @(Get-C9EnvironmentData -EnvironmentId $c9_id)
    $objResults = New-Object PSObject -Property @{
        Arn = $c9_data.Arn;
        Name = $c9_data.Name;
        OwnerArn = $c9_data.OwnerArn;
    }
    $arrResults += $objResults
}

Write-Output $arrResults

# 実行結果
OwnerArn                                                                        Name                  Arn                                                                                    
--------                                                                        ----                  ---                                                                                    
arn:aws:iam::[account_id]:user/hoge                                             hogehoge              arn:aws:cloud9:[region名]:XXX:environment:[EnvironmentId]
・・・

# 実行結果のId使ってメンバー追加
aws cloud9 create-environment-membership --environment-id [EnvironmentId] --user-arn arn:aws:sts::[account_id]:assumed-role/[role-name]/[AssumeRoleするIAMユーザー名] --permissions read-write/read-only --region [region名]

せっかく設定しても残念だったこと

IAM ロールを使用する の制限でなんとセッション時間１時間から延長できないので、１時間でセッション切れちゃう。使い勝手悪いのでなんとかなったら嬉しいんですがね。

Glueジョブで環境変数を使う

STAGE = prd を環境変数として、この環境変数を表示するだけのジョブを実行する

ジョブの中で環境変数を定義してジョブ実行する

ジョブの追加

Glueの画面から、左側メニューの"ジョブ"をクリックし、[ジョブの追加]をクリックし、以下の値を入力する

名前：se2_job18
ユーザーが作成する新しいスクリプト：チェック

下の方に行き、以下の箇所をクリック

キー:--STAGE
値:prd

入力したら[次へ]をクリックし、次の画面で[ジョブを保存してスクリプトを編集する]をクリックし、以下のスクリプトを貼り付け、[ジョブの実行]をクリックする

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME','STAGE'])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

print(args['STAGE'])

job.commit()

成功したら画面の"ログ"と書かれた箇所をクリックし、CW Logsでprdが表示されたか確認する

表示された

環境変数をファイルに書き、S3に配置したものを使う

S3に環境変数ファイルをアップロード

s3://test-glue00/se2/env.conf

[Environment]
STAGE: prd

ジョブの追加

Glueの画面から、左側メニューの"ジョブ"をクリックし、[ジョブの追加]をクリックし、以下の値を入力する

名前：se2_job19
ユーザーが作成する新しいスクリプト：チェック
キー:--env
値:s3://test-glue00/se2/env.conf

入力したら[次へ]をクリックし、次の画面で[ジョブを保存してスクリプトを編集する]をクリックし、以下のスクリプトを貼り付け、[ジョブの実行]をクリックする

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job
import ConfigParser
import StringIO
import boto3

## @params: [JOB_NAME]
args = getResolvedOptions(sys.argv, ['JOB_NAME','env'])

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

str = args['env']
list = str.split('/')
key = str.split("/")[3] + "/" + str.split("/")[4] + "/" + str.split("/")[5]

s3 = boto3.resource('s3')
obj = s3.Object(list[2], key)
buf = StringIO.StringIO(obj.get()['Body'].read().decode('utf-8'))

config = ConfigParser.ConfigParser()
config.readfp(buf)
print config.get('Environment', 'STAGE')

job.commit()

成功したら画面の"ログ"と書かれた箇所をクリックし、CW Logsでprdが表示されたか確認する

表示された

こちらも是非

Glueの使い方まとめ
https://qiita.com/pioho07/items/32f76a16cbf49f9f712f

ふとAWSを使おうと思い、以下を参考にした。
AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ

ただ、IAMユーザの作成でちょっとUIが変わっていたのでその辺りをまとめておく。

そもそもIAMユーザって何？

IAMはIdentity and Access Managementの略。AWSへのアクセス権限を人やAWS以外のサーバに付与するためのもの。ただ、自分一人しか使わない場合でも、常にAWSアカウントを作った時のルートユーザで作業し続けるのは危険なので、最低限の権限を与えたIAMユーザで作業するのがベストプラクティスらしい。

IAMユーザの作成

1.　IAMのページにアクセス
2.　個々のIAMユーザーの作成をクリックし、ユーザーの管理をクリック

3.　ユーザーを追加をクリック

4.　ユーザー名を入力してAWSマネジメントコンソールへのアクセスにチェックを入れ、パスワードを入力して次のステップをクリック

5．グループの作成をクリック

6．グループ名を入力し、AdministratorAccessにチェックを入れてグループの作成をクリック

7．次のステップをクリック

8．タグの必要性はよくわからないので適当に入力するか空欄で次のステップをクリック

9．ユーザーの作成をクリック

10．完了

二段階認証の導入

1.　IAMのページにアクセスして左側のメニューからユーザーをクリック
2.　設定するユーザーを選択

3.　認証情報タブに移動し、MFAデバイスの割り当ての管理をクリック

4.　ここではAuthenticatorを使うことを想定しているので仮想MFAデバイスを選択し、続行をクリック

5.　AuthenticatorでQRコードを撮影し、MFAコードを2回連続入力して完了

初めに

Cognitoを使用中、デプロイ時に

No integration defined for method

とエラーが出てくることがある。

この対象法を紹介

結論

このエラーは統合リクエストの編集不足でエンドポイント等が存在しないAPIがある可能性が高い
なのでデプロイするリソースのAPIを調べてみて該当するものがないか確認する。

合致するものがあればとりあえずMOCK設定でデプロイしてパスするかどうかを確認する

自分はこれで処理できた

終わりに

No integration defined for method
だけじゃなくてどのAPIがエラーなのかも教えてくれると嬉しいな、、、

1. ドメインを取得する

自分はここから取得しました
https://muumuu-domain.com/

2. ACMで証明書の作成

まず証明書のプロビジョニングを選択します。

パプリック証明書のリクエスト

パプリック証明書を選択します。

STEP1 ドメイン名指定

取得したドメイン名を貼ります。

STEP2 検証方法の選択

指定したドメインの所有権が本当にあるのか検証します。

今回はEmailを使用して検証します。

STEP3 確認とリクエスト

ただの確認画面

STEP4 検証

DNSに登録したアドレスに検証メールが飛んできます。
メールに記載のリンクを踏んで、「I approve」を押してアクティベートします。

3. API Gatewayの設定

メニューから「カスタムドメイン名」を選択して設定します。

カスタムドメイン名取得

ドメイン名： 取得したドメイン名
エンドポイントの設定： Regional
ACM証明書： 先程作成したもの

「保存」を押すと作成されます。（少し時間がかかります）

ターゲットドメイン名を確認

Route53で設定するので控えておいてください。

ベースパスマッピングの変更

URLとAPIのマッピングを行います。
これはAPIの設計次第なので割愛。

4. DNSの設定を行う

DNSもAWSで一括管理したいのでAWS Route53を使用します。

Route53の設定

1. 「Hosted Zone」→「Create Host Zone」を開く
2. ドメイン名を入力して作成
3. NSレコードを控えます
4. AAAAレコードを追加します
   • Alias: Yes
   • Alias Target: API Gatewayを指定します
     

ドメイン管理側の設定変更

ドメインサービスの独自DNSからRoute53を使うように変更します

ムームードメインの場合
「ドメイン管理」→「ドメイン操作」→「ネームサーバー設定変更」

1. GMOペパボ以外 のネームサーバを使用する
2. ROUTE 53のNSレコードを指定します。

参考文献

ACMの設定
https://qiita.com/aokabin/items/b03850c450d50abed952

API Gateway側の設定。
少し情報が古いです。
https://dev.classmethod.jp/cloud/aws/api-gateway-with-custom-domain/

はじめに

AmazonComprehend(AWSの自然言語処理サービス)のAPIを、Python3から実行してみました。幾つかの記事を参考にさせて頂きましたが、一つにまとまっているものはなかったので、それらをまとめてみました。

環境

MacOS Sierra 10.12.6
python 3.7.0

インストール

$ sudo pip install awscli

次に、AWSアクセスキーを取得する。
参考サイト：

• インストール https://qiita.com/reflet/items/e4225435fe692663b705
• AWSアクセスキー https://aws.amazon.com/jp/developers/access-keys/

AWSアクセスキーは、リクエストを正常に AWS API に送信するために必要、とのことです。

AWSアクセスキーの取得

以下の記事を参照してください。
https://qiita.com/miwato/items/291c7a8c557908de5833

プログラムの実行

以下の記事にサンプルコードや結果がまとめられています。
https://dev.classmethod.jp/cloud/comprehend-operations-using-python-boto3-ja/

感想

Qiita初投稿、ということもあり、至らぬ点やアドバイスいただけると幸いです。
また参考にさせて頂いた記事の著者の皆様、ありがとうございました。

初めに

Cognitoでユーザー作成するときなどにUserAttribute属性指定することありますよね、

自分はcliでシェルスクリプト作っていたのですが、UserAttribute属性を複数個指定する書き方を少し悩んだので共有します。

結論

aws cognito-idp admin-create-user 
--user-pool-id ap-northeast-1_hogehoge
--username test 
--message-action SUPPRESS 
--user-attributes Name=email,Value=hoge@gmail.com Name=email_verified,Value=True

みていただきたいのは--user-attributesの箇所です。

この書き方で複数個属性指定することができました。

こちらのコマンドは改行挟んでますのでエラーでます。お気をつけください

終わりに

AWSは無限に新しいサービスが出現するイメージで終わりが見えません

一つ一つキャッチアップしていきます！！！

スタートライン

現在はiOSエンジニアとして働いていますが、以前はネットワークに関連した映像機器やLSIなどを開発していたのでLinuxやネットワークに関する知識はそこそこありました。

また前職ではiOSアプリ開発の傍、EC2やMySQL、Nginx、Nodeを使ったRESTful APIサーバ、iOSアプリ用のサーバサイドを構築しました。プロダクションにはなっていないのですが、いい経験でした。AWSは興味があって情報は色々集めていたのですが、実際に手を動かしていたのはその程度です。

勉強方法

同僚にすごい人たちが多いので、色々話を聞いて参考にしました。

1. 合格対策 AWS認定ソリューションアーキテクト －アソシエイトを１回読みました
2. Linux AcademyでAWS Certified Solutions Architect Associate Level (2018)を受講しました
3. WEB問題集を約２周（1600問）しました。

合格対策 AWS認定ソリューションアーキテクト －アソシエイト

正直あんまり頭に入ってきませんでした。概要を掴む効果はあります。他の対策に時間を掛けたので結局最初に１度だけ読んだだけです。

Linux Academy

28時間以上あります。試験までに自分は70%しか受講することができませんでした。VPC、EC2、RDS、S3、Route53、VPC Peering、SNS、SQSあたりまで。
英語なので難しい内容は理解しにくいものもありましたが、実際にAWSアカウントを使った実技演習が合間合間にあり、とても効果的でした。この演習はAWSの利用に時間制限があり、途中までやってご飯を食べていたら最初から、なんてこともありました。ご注意ください。

WEB問題集

全116回（約800問）を約２周やりました。これは効果的です。前の２つをやった上で問題を解き、間違った時の解説を読み、さらにわからない時はAWSのドキュメントを読む、というやり方です。Linux Academyで実技演習をやっているので、説明が頭に入ってきます。

試験

渋谷で試験を受けました。詳しくは書けませんが、最初にチャットでなんか指示があると思って待っていたら何もなく、なんか押して良いのかどうかわからない画面のボタンを押して試験開始しました。もうちょっと説明欲しかったかな。
問題数は秘密のようですが、十分な時間があるので焦る必要はなく、じっくり考えても大丈夫です。自分は１時間程度で終了しました。

合格後

AWS Certified Solutions Architect - Associateに合格すると、AWSの模擬試験を無料で受けることができます。
他のAssociateを受ける予定の方は、まずSAAに合格してから次の試験に向かうと、少しお得かもしれません。

1. はじめに

ここでは、AWS上でハニーポット「T-Pot」を動作させるためのインスタンス作成についてご紹介します。
なるべくワンステップごとの手順を紹介していますが、AWSに慣れてる方はどんどん飛ばしてご覧ください。

なお、AWS上でのT-Pot運用に関しては、以下の記事を参考にさせていただきました。ありがとうございます。

Amazon EC2(t2.medium)でT-Pot構築(その1)
https://graneed.hatenablog.com/entry/2018/06/10/030525

EC2上にHoneypot(T-Pot)をインストールして、サイバー攻撃をELKで可視化してみた
https://qiita.com/tarosaiba/items/871ab0c155578f8a38fe

2. インスタンス作成の前に

作成するインスタンスに関して、以下の内容ぐらいは事前に把握しておくとスムーズだと思います。
マニアックな方はご自由にどうぞ。

• インスタンスのシステム要件
• 実際に作成するインスタンスのスペック
• インスタンスを設置するリージョン
• これらを踏まえた予測コスト

2.1 インスタンスのシステム要件

T-Potの主なシステム要件について抑えておきましょう。

T-Pot
https://github.com/dtag-dev-sec/tpotce

System Requirementsにはいくつかのタイプが紹介されていますが、
Standard Installationでは次の通りです。

• OS: Ubuntu 18.04.x LTS
• 6～8GB RAM
• 120GB SSD

2.2 実際に作成するインスタンスのスペック

以下のインスタンスをデフォルト設定で作成することとします。

• Ubuntu Server 18.04 LTS (HVM), SSD Volume Type
• t2.large
• 汎用SSD 120GB

2.3 インスタンスを作成するリージョン

リージョンによってインスタンスの料金が若干異なります。
今回は「米国西部 (オレゴン)」としました。
観測を行いたいリージョンにこだわりがあれば、そのリージョンを選択しましょう。

2.4 予測コスト

一ヶ月ぐらい動かしっぱなしにして、請求を見て、うおーー(＠_＠;)ってなることがないように、
「AWS 簡易見積りツール」を使って、予測コストを把握しておきましょう。

私の場合は、お小遣い程度で遊べたらいいなーという予算感です。
予算を上回る場合は、調査期間やスペックの見直しを。

AWS 簡易見積りツール
https://calculator.s3.amazonaws.com/index.html?lng=ja_JP#

先ほど決めたスペックを入力して、ざっくりと見積もってみます。
とりあえず、検証だけなので3日間ぐらいの稼働で、構築完了したらスナップショット取っておこうかなと、そんな感じ。
GuardDutyは無料枠を使って、S3とかCloudWatchとかは、誤差の範囲ということで。（適当）

3000円弱ですかね。後ほど請求アラームを設定しようと思いますが、これを目安にします。

以上で問題なさそうなので、構築していきましょう。

3. AWSの登録

既存のAWSアカウントを使いました。
（ベストプラクティス的には、ユーザを作成してIAMロールを割り当てた方がいいと思いますがｗ　良い子は真似しないでね。）
AWSのアカウントがない方は、アカウント登録をしましょう。
登録方法はたくさん紹介されていると思うので省略します。
※無料枠の案内もありますが、今回利用するT-potは無料枠のインスタンスでは動作しませんのでご注意を。

https://aws.amazon.com/jp/

4. EC2インスタンスの作成

T-Potのシステム要件を満たすEC2インスタンスを作成していきます。

4.1 マネジメントコンソールからEC2コンソールを開く

EC2で検索してサジェストされた候補「EC2」をクリックします。（AWSってめっちゃサービスありますからね、、、）

こんな画面ですね。

4.2 リージョンを選択

今回ハニーポットを設置したい「リージョン」を選択しましょう。

これで、当該リージョンのEC2インスタンスのコンソールが表示された状態です。

4.3 インスタンスの新規作成開始

「インスタンスの作成」をクリックします。

4.4 AMIの選択

Ubuntu Server 18.04 LTS (HVM), SSD Volume Type」を選択します。
アーキテクチャはデフォルト（x86）のままで。

4.5 インスタンスタイプの選択

「t2.large」を選択し、次の手順をクリックします。

4.6 インスタンスの詳細の設定

デフォルトのままでも大丈夫です。次の手順をクリックします。

4.7 ストレージの追加

デフォルトで汎用SSDが選択されています。
サイズを120GBに変更します。

4.8 タグの追加

何も設定しなくてもOKです。後からでも追加できます。
一応、machine-name: t-pot-01とマシン名のタグを付けておきます。

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

いよいよ終盤です。
セキュリティグループは、現時点では自身のIPからのSSH接続のみ許可しましょう。（これ重要）
後ほどハニーポットのセットアップの過程で、SSHのポート変更やハニーポット用のポート開放も行います。
わかりやすいように、セキュリティグループ名もt-pot-01としておきます。

4.10 インスタンス作成の確認

設定に間違いがないか確認し、間違いがなければ「起動」をクリックします。課金が開始されるので注意しましょう。

5. 起動確認

ダッシュボード上にインスタンスが作成されたことがわかります。
pendingの表示がrunningに変わったら、起動完了です。

6. インスタンスへの接続

「接続」から、作成したキーペアを使用して、インスタンスに接続します。
わからなかったらGoogle先生が教えてくれます。

7. 接続完了！

無事ログインできたら、インスタンスの作成完了です。
T-Potインストール中にこけることもあるので、ここでスナップショット取っておけたらベストですね。

8. まとめ

まずはT-Pot用のインスタンス作成まで完了しました。
新規登録したAWSアカウントでも、今回作成するインスタンスは無料枠に収まらないので注意が必要ですね。
また、セキュリティグループの設定は、現時点では自身のIPからのSSH接続のみの許可です。
それ以外は、AWSのEC2を使ったことがあれば、特に困ることはないかと。
次の手順で、T-Potのセットアップを行っていきます。

前段

かつてはyarn自体のバージョンをアップデートするコマンドとして、yarn self-updateがあったようです。
https://yarnpkg.com/lang/ja/docs/cli/self-update/

しかし、残念ながらこのコマンドは利用できないので、別の方法を取らざるえない様子。

ローカルのyarnはbrewで入れていたので、さっくり上がったものの、問題はサーバー側。
調べた限り、サーバー側でyarnのアップデートをしている記事が少なかったので、症例報告としてこの記事を書きます。
下記手順が安全であることや正規の方法であることを保証できませんので、そのつもりでお願いします。

私の環境では yarn 0.27.5→1.13.0のアップデートを実施しました。（Amazon　Linax）

npmでyarnを入れた場合

私の環境では、後述の理由でnpmを使わずyarnがインストールされていました。

npmで導入した場合、こちらの記事が参考になりそうです。
yarn自体のアップグレードをする

yumでyarnを入れた場合

yarn公式ではnpmを使ってyarnを導入することを非推奨としているようです。

注意: npm から Yarn をインストールすることは一般的にはお勧めしません。 Node ベースのパッケージマネージャで Yarn をインストールする場合は、パッケージは署名されておらず、整合性のチェックはベーシックな SHA1 ハッシュのみで行われており、システム全体にまたがるアプリケーションをインストールする場合にはセキュリティリスクとなります。
これらの理由から、使用中の OS に最も適した方法で Yarn をインストールすることを強くお勧めします。
https://yarnpkg.com/ja/docs/install#alternatives-stable

今回私が対応した環境でもこの記述に準じて行われておりyarnがyumを使って導入されていました。
なので sudp yum update yarnでいけるかな...と試して見たんですが、アップデートは走るものの、サーバーを再起動してもversionは変わらないままだったので、下記の方法でアップデートを行いました。

ここからは2ステップででアップデートの方法を書きます。

1.古いyarnをアンインストール
2.新しいyarnをインストール

1.古いyarnをアンインストール

基本的には下記で導入されたものを打ち消す方向で動くことになります。
https://yarnpkg.com/ja/docs/install#centos-stable

まずyarnがどこにあるか調べます。調べるだけです。

$which yarn  

yum経由でyarnをアンインストールします。

$sudo yum remove yarn

yarnがアンインストールされていることを確認するためにyarnのバージョンを表示を試してみます。

$yarn --version

①コンソールから「そんなコマンド無いよ」的なことが言われた場合

yarnのアンインストールに成功しています。
次に、かつてyarnをインストールするときにダウンロードしたであろう、yarn.repoを削除します。

$cd /etc/yum.repos.d/

上記フォルダの中にyarn.repoが入っていたのでこれを削除しました。

$sudo rm -f yarn.repo

②平然とyarnのバージョンが帰ってきた場合

yarnのアンインストールが完了していなさそうです。

困ってしまったのでyarnの公式からもリンクされている下記issueを参考にして進めました。
https://github.com/yarnpkg/yarn/issues/1139#issuecomment-441168002

まず先ほど$which yarnで調べた場所を見にいきます。そこに入っている yarn と yarnpkg というファイルを削除してみます。

$rm -f yarnpkg
$rm -f yarn

これで$yarn --versionしてもコマンドが通らなくなりました。
yarnが通らなくなったことが確認できたので上記の2ファイルが入っていたディレクトリを削除します。
私の場合　.yarnにyarn と yarnpkgが入っていたので削除します。

$rm -rf .yarn

次に、かつてyarnをインストールするときにダウンロードしたであろう、yarn.repoを削除します。

$cd /etc/yum.repos.d/

上記フォルダの中にyarn.repoが入っていたのでこれを削除しました。

$sudo rm -f yarn.repo

2.新しいyarnをインストール

基本的に公式のインストールを再びなぞります。
https://yarnpkg.com/ja/docs/install#centos-stable

$curl --silent --location https://dl.yarnpkg.com/rpm/yarn.repo | sudo tee /etc/yum.repos.d/yarn.repo
$sudo yum install yarn
$yarn --version
1.13.0であることを確認

おわりに

上記でうまくいってしまいましたが、ビギナーズラックだったかもしれません。
あくまで一例として紹介させていただきます。

本記事でやること

• 前回の記事で行なったトレーニングジョブ結果から生成されたモデルのデプロイを行う。
• S3に置いてあるデータをまとめて推論するバッチ変換ジョブを実行する。

本記事でやらないことは以下の通りなので、他の記事を参照してください。

• 前回の記事で行なった独自アルゴリズムを使ったトレーニングジョブの実行方法
• SageMakerやS3などにアクセスするためのIAMロールの作成

対象読者

• とりあえずAWS SageMakerを動かしてみたい人
• Dockerに関して一通りの基礎知識がある人

使用言語

• Python 3.6.3

トレーニングジョブ結果から生成されたモデルのデプロイを行う

公式ドキュメントに記載がある通り、推論を行う際にアプリケーションがリクエストを送るエンドポイントは、モデルをデプロイした際に取得されます。なので、トレーニングジョブが完了された後にモデルのデプロイを必ず行う必要があります。

以下、コードからモデルのデプロイを行います。

class SagemakerClient:

    def __init__(self):
        self.client = Session(profile_name="hoge").client("sagemaker", region_name="ap-northeast-1")

    def create_model(self, model_data_url):

        model_params = {
            "ExecutionRoleArn": "arn:aws:iam::123:role/dev-sagemaker", 
            "ModelName": "sample-model", # モデル名
            "PrimaryContainer": {
                "Image": "123.dkr.ecr.ap-northeast-1.amazonaws.com/sagemaker-repo:latest", # ECRにプッシュしたイメージURL
                "ModelDataUrl": model_data_url # モデルデータが格納されているS3のパス
            }
        }

        self.client.create_model(**model_params)


if __name__ == '__main__':
    model_data_url = ...
    SagemakerClient().create_model(model_data_url)

上記コードでのcreate_modelメソッドの引数（model_data_url）は、boto3のdescribe_training_jobから得られるのでこちらの公式ドキュメントをご参照ください。

参考程度にmodel_data_urlを取得するコードを以下に記載いたします。また、describe_training_jobの引数TrainingJobNameはトレーニングジョブを送信する際に返ってくるTransformJobArnから取得をしています。

client = Session(profile_name="hoge").client("sagemaker", region_name="ap-northeast-1")

model_data_url = client.describe_training_job(TrainingJobName=training_job_name)['ModelArtifacts']['S3ModelArtifacts']

以下のようにAmazon SageMaker > モデルにモデルが現れていれば無事完了です。

S3に置いてあるデータをまとめて推論するバッチ変換ジョブを実行

今回、推論時に使用したデータや推論結果の出力先などは以下のようなフォルダ構成でS3に置きました。

bucket
├── input-data-prediction
│     └── YYYY-MM-DD
│          └── multiclass
│               └── iris.csv
├── output-data-prediction
│     └── YYYY-MM-DD
│          └── multiclass
│               
├── input-data-training
│     └── YYYY-MM-DD
│          └── multiclass
│               └── iris.csv
└── output-model
     　└── YYYY-MM-DD
          　└── multiclass
               　└── model名（←ここからはSageMakerが出力する）

以下のコードからバッチ変換ジョブを送信します。
ジョブを送信する際の引数であるModelNameは、デプロイしたモデル名を使用します。
デプロイしたモデル名は、boto3のlist_modelsメソッドで得られるのでこちらの公式ドキュメントをご参照ください。（モデル名に含まれている文字列とデプロイした時間からしか検索ができないみたいです）

class SagemakerClient:

    def __init__(self):
        self.client = Session(profile_name="hoge").client("sagemaker", region_name="ap-northeast-1")

    def submit_transform_job(self):

        model_name = self.client.list_models(
            NameContains="base_model_name", # 各自デプロイしたモデル名に含まれている文字列
            SortOrder='Descending',
            SortBy='CreationTime')["Models"][0]["ModelName"]

        transform_params = {
            "TransformJobName": "sample-transform_job_name", #　バッチ変換ジョブ名
            "ModelName": model_name, # デプロイしたモデル名
            "MaxConcurrentTransforms": 2,
            "MaxPayloadInMB": 50,
            "BatchStrategy": "MultiRecord",
            "TransformOutput": {
                "S3OutputPath": "s3://bucket/output-data-prediction/YYYY-MM-DD/multiclass/" # 推論結果を格納するS3パス
            },
            "TransformInput": {
                "DataSource": {
                    "S3DataSource": {
                        "S3DataType": "S3Prefix",
                        "S3Uri": "s3://bucket/input-data-prediction/YYYY-MM-DD/multiclass/" # 推論を行うインプットデータが格納されているS3パス
                    }
                },
                "ContentType": "text/csv",
                "SplitType": "Line"
            },
            "TransformResources": {
                "InstanceType": "ml.c4.xlarge",
                "InstanceCount": 1
            }
        }

        self.client.create_transform_job(**transform_params)

if __name__ == '__main__':
    SagemakerClient().submit_transform_job()

以下のようにAmazon SageMaker > バッチ変換ジョブでステータスがCompletedになれば無事完了です。上記で指定したS3のパスに推論結果が格納されているはずです。

終わりに

今回は、モデルをデプロイ~バッチ変換ジョブを送信するコードのみを記載しましたが、SageMakerのDockerコンテナ内にあるpredictor.pyやserveは公式のgithubにあるサンプルをそのまま使用しています。

はじめに

この記事は、筆者がAWSを勉強していた際、サブネット作成時にハマったことを備忘録として書き留めた記事です。

前提

• AWSにてブラウザ上などからVPCをすでに作成してあること

結論

サブネットを作成する際には、VPC作成時のCIDRを指定すると(10.0.0.0/24など)重複エラーになる。
RDSを作成するときのようにサブネットを複数作る際には、

10.0.0.0/27
10.0.0.32/27

のように同一のサブネットマスク内で指定範囲をずらして設定するといい。

※ここから下は余談なので、結論から知りたい方はリターンください

この記事を書こうとした背景

AWSについてもっと色々と知りたい、知識を深めたいと思っていたので、以下の記事を参考にしながら学習を進めていたんですよ。

Qiita記事

(DB・サーバー構築編)世界一丁寧なAWS解説。EC2を利用して、RailsアプリをAWSにあげるまで

で、下準備編も順調に終わり、さあRDSを作成するぞ！となったとき、DB用のサブネットグループを作成し忘れていたことに気づいたんです。

じゃあ、作らなきゃとなったとき、

CIDR アドレスは既存のサブネット CIDR と重複しています: 10.0.0.0/24

と表示されたので、しょうがないな。。。と思い「10.0.1.0/24」で作成することにしました。

でも、CIDR アドレスが VPC からの CIDR アドレス内にありません と表示されちゃうので、30分くらいハマったんですね。

色々と調べていくと、どうやら最初のサブネットを作成するときにVPCのCIDRを作成していることが原因だったようです。

つまり、2つ目以降にサブネットを同じVPCに紐づけて作ろうと思っても、すでに1つ目でVPC自体のCIDRを使っているので、ユニーク制約により使用できないということ。

そのため、サブネットを作成する際にはVPCで設定したCIDRの有効範囲内で、それぞれ個別に設定してあげるというのがポイントです。

このポイントがわかったところで、それぞれのサブネットを例えば、

10.0.0.0/27
10.0.0.32/27

のように設定してあげると、問題なく作成することができました。

CIDRって？

正式名称は、Classless InterDomain Routing。サイダーと発音しますが、炭酸水ではないです。

詳しくは以下のサイトをどうぞ。
CIDRとは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

参考サイト

チュートリアル: Amazon RDS DB インスタンスで使用する Amazon VPC の作成

VPCとサブネットについて

AWS VPC環境構築

サブネットの設定について

はじめに

2018年1月25日にAWS東京リージョンにも4つ目のAvailabilityZone(以下、AZ)であるAZ-dが登場し、現在EC2インスタンスを配置できるAZはAZ-a、AZ-c、AZ-dの3つになっていると思います。

【参考】
・東京リージョンに新たにアベイラビリティゾーンを追加

HadoopやElasticsearchのような並列分散型アーキテクチャのシステムを東京リージョンで構築しようとするとこれまではAZ-aとAZ-cの2つのAZしか選択できず、AZ障害時はクォーラムを維持出来なくて困っていた方が多いのではないでしょうか。ちなみに自分もその一人です(笑)

せっかくなので、AZ間のネットワーク遅延を測定してみようかなと。。。

構成図

AW東京リージョンに3つのAZ(それぞれサブネット)を作成して、測定用のEC2インスタンスを配置ました。
各EC2インスタンスから双方向にPing200発打ってネットワーク遅延を測定しました。

Region	Subnet	IPv4 CIDR	Availability Zone	AZ ID※1
ap-northeast-1	Subnet01	172.31.16.0/20	ap-northeast-1a	apne1-az4
ap-northeast-1	Subnet02	172.31.0.0/20	ap-northeast-1c	apne1-az1
ap-northeast-1	Subnet03	172.31.32.0/20	ap-northeast-1d	apne1-az2

※1: re:Invent 2018で発表されましたが、各AZが物理的にどこのAZにマッピングされているのか判断出来るようにAZ IDというIDが表示されるようになりました。

さて実測！！

実測してみると以下のような感じでした。

①AZ-a(az4)→AZ-c(az1)

[ec2-user@ip-172-31-31-77 ~]$ ping 172.31.8.169
PING 172.31.8.169 (172.31.8.169) 56(84) bytes of data.
64 bytes from 172.31.8.169: icmp_seq=1 ttl=255 time=2.89 ms
64 bytes from 172.31.8.169: icmp_seq=2 ttl=255 time=2.58 ms
64 bytes from 172.31.8.169: icmp_seq=3 ttl=255 time=2.70 ms
64 bytes from 172.31.8.169: icmp_seq=4 ttl=255 time=2.62 ms
64 bytes from 172.31.8.169: icmp_seq=5 ttl=255 time=2.55 ms
<以下省略>

②AZ-a(az4)→AZ-d(az2)

[ec2-user@ip-172-31-31-77 ~]$ ping 172.31.32.168
PING 172.31.32.168 (172.31.32.168) 56(84) bytes of data.
64 bytes from 172.31.32.168: icmp_seq=1 ttl=255 time=1.73 ms
64 bytes from 172.31.32.168: icmp_seq=2 ttl=255 time=1.74 ms
64 bytes from 172.31.32.168: icmp_seq=3 ttl=255 time=1.73 ms
64 bytes from 172.31.32.168: icmp_seq=4 ttl=255 time=1.76 ms
64 bytes from 172.31.32.168: icmp_seq=5 ttl=255 time=1.81 ms
<以下省略>

③AZ-d(az2)→AZ-c(az1)

[ec2-user@ip-172-31-32-168 ~]$ ping 172.31.8.169
PING 172.31.8.169 (172.31.8.169) 56(84) bytes of data.
64 bytes from 172.31.8.169: icmp_seq=1 ttl=255 time=1.07 ms
64 bytes from 172.31.8.169: icmp_seq=2 ttl=255 time=1.07 ms
64 bytes from 172.31.8.169: icmp_seq=3 ttl=255 time=0.930 ms
64 bytes from 172.31.8.169: icmp_seq=4 ttl=255 time=0.943 ms
64 bytes from 172.31.8.169: icmp_seq=5 ttl=255 time=1.03 ms
<以下省略>

上記の結果を集計するとこんな感じになりました。
多少のばらつきはありましたが、200発実施結果の平均値を見て頂ければ概ね間違いはないと思います。

まとめ

実測してみると2つのAZを利用して冗長化するのであれば、apne1-az1とapne1-az2にマッピングされたAZを利用してシステムを組んだ方がネットワーク遅延によるデメリットは少なそうですね！！
(ELBでクロスゾーン負荷分散するケースやAmazon RDSでマルチAZ配置するケースなど)

いずれにしてもEC2でElasticsearchのクラスタを組むことが多い私にとってはAZ-dの存在は嬉しい限りですが^^

AWSアカウント単位でAZ IDのマッピングがされてしまいますので、私のアカウントでは残念ながらaz3は出てこず測定はできませんでした。やはりaz-3はあるんですよね。。

起こったこと

絵文字入りのCSVファイルに対し、S3 Selectでクエリを投げてみます。

アップロードしたCSV

v_name,oshimark
周防パトラ,?❤️
蒼月エリ,??
島村シャルロット,♣️❄️
西園寺メアリ,??
堰代ミコ,??

SQL

select * from S3Object s where s.v_name = '周防パトラ' -- -> 周防パトラ,?❤️
select * from S3Object s where s.v_name like '%パ%' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark = '?❤️' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark like '%❤️%' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark like '%?%' -- -> 結果がありません

ん？

サロゲートペア文字が原因（っぽい）

Where likeでうまく結果をとれた「❤️」は、UTF-16のコードポイント上で U+2764 と U+FE0F (異体字セレクタ) ️で構成された文字に対し、「?」は U+1F980 のサロゲートペア文字です。
同じくサロゲートペア文字である「?」「?」なども、Where likeで取得することができませんでした。

一方で、非サロゲートペア文字＋異体字セレクタで構成された「♣️」などはちゃんとで取得できました。

AWS側のバグなのでしょうか・・・。

対策

絵文字がそのまま使えない以上、別のフォーマットで保存するほか無さそうです。
私の場合は、URLエンコードをかけた形式で保存することで対応しました。

v_name,oshimark
周防パトラ,%F0%9F%A6%80%E2%9D%A4%EF%B8%8F
蒼月エリ,%F0%9F%A5%80%F0%9F%92%8E
島村シャルロット,%E2%99%A3%EF%B8%8F%E2%9D%84%EF%B8%8F
西園寺メアリ,%F0%9F%8D%BC%F0%9F%94%AE
堰代ミコ,%F0%9F%94%B1%F0%9F%8D%8F

起こったこと

絵文字入りのCSVファイルに対し、S3 Selectでクエリを投げてみます。

アップロードしたCSV

v_name,oshimark
周防パトラ,?❤️
蒼月エリ,??
島村シャルロット,♣️❄️
西園寺メアリ,??
堰代ミコ,??

SQL

select * from S3Object s where s.v_name = '周防パトラ' -- -> 周防パトラ,?❤️
select * from S3Object s where s.v_name like '%パ%' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark = '?❤️' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark like '%❤️%' -- -> 周防パトラ,?❤️
select * from S3Object s where s.oshimark like '%?%' -- -> 結果がありません

ん？

サロゲートペア文字が原因（っぽい）

Where likeでうまく結果をとれた「❤️」は、UTF-16のコードポイント上で U+2764 と U+FE0F (異体字セレクタ) ️で構成された文字に対し、「?」は U+1F980 のサロゲートペア文字です。
同じくサロゲートペア文字である「?」「?」なども、Where likeで取得することができませんでした。

一方で、非サロゲートペア文字＋異体字セレクタで構成された「♣️」などはちゃんとで取得できました。

AWS側のバグなのでしょうか・・・。

対策

絵文字がそのまま使えない以上、別のフォーマットで保存するほか無さそうです。
私の場合は、URLエンコードをかけた形式で保存することで対応しました。

v_name,oshimark
周防パトラ,%F0%9F%A6%80%E2%9D%A4%EF%B8%8F
蒼月エリ,%F0%9F%A5%80%F0%9F%92%8E
島村シャルロット,%E2%99%A3%EF%B8%8F%E2%9D%84%EF%B8%8F
西園寺メアリ,%F0%9F%8D%BC%F0%9F%94%AE
堰代ミコ,%F0%9F%94%B1%F0%9F%8D%8F

冬休みの自由研究的な

そんなノリでやってみました。
結果は正直微妙でしたが、個人的にGuardDuty使ったのは初めてだったので、いい勉強になりました。
長くなりそうなのでいくつかの記事に分けて掲載しようかと思いますが、最終的にはこれ↓がたくさん出たよって話です。

よろしければお付き合いください。

AWSでハニーポット用インスタンスを準備する

まずはT-Potを動かすためのインスタンスを作成します。
無料枠にも収まらないので、コストも意識しながら勧めていきます。
慣れている方なら、記事は読まずに以下のスペック以上のEC2インスタンスを作成してください。
セキュリティグループでは、現時点では自身のIPのSSH接続(22/TCP)のみ許可します。

• Ubuntu 18.04 LTS x86-64
• t2.large
• 120GB SSD

AWSでハニーポット（T-Pot）用インスタンスを準備する
https://qiita.com/yifey/items/f91d1a02714ba7a563ba

T-POTのセットアップ

TBH

GuardDutyのセットアップ

GuaradDutyのセットアップは驚くほど簡単でした。
しかもトライアルで無料でしたし。AWS先生ありがとうございます！
数年前にクラウド上で初めてEC2インスタンス建てたときの手軽さと同じかそれ以上の感動です笑
サンプルログの出力や、CloudWatchとの連携などを確認してみました。

GuardDutyの有効化
https://qiita.com/yifey/items/e260ee318a5cd8f566ce

ロ、ログがでた！が、、

TBH

まとめ

GuardDutyを使い始めるまでの簡単さには驚きました。
IDSとして、ネットワークベースで不審な動作を検出できるのは良いですね。
ただ、ハニーポット上の出力と比べると、情報量がかなり違うので、
これだけに頼るのはちょっと難しいのかなという印象もありました。（もともとそういう意図で設計されてはいないと思いますが。）
GuardDutyのFindingsベースでLambdaの関数を動作させることもできるので、近未来的にはIRの自動化とかもできるのかな。

AWS（とインフラも）初心者の私が、AWSの勉強をはじめました。
そこで、これまでどんな勉強したかまとめておきます。
インフラ初心者の方等に参考になれば幸いです。

モチベーションの保ち方

個人的には下記の進め方があっています。
知らないワードがいっぱいでてくると、急激に疲れてきます。。

・最初から難しい本を読まない。（自分でもわかりそうだなって本から）
・すぐにわからないことは、ToDoとして置いといて先へ進む。
・疲れたら別のことやる。
・気になっていることがあったら、その気持ちを利用してすぐ調べる。

今までのAWS勉強の流れ

1. 初心者でも読めそうな本を読む

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版

実際にAWSで手を動かしながら学ぶことができます。
内容も難しくなく、yumってなんぞレベルの私でもすんなりよむことができました。
そんなに分厚くもないので、導入としてはよかったかなと今振り返って思っています。
AWSには無料利用枠というものがあり、それを活用させていただきました。
https://aws.amazon.com/jp/free/

2. わかりやすそうな動画を見る

手を動かしながら2週間で学ぶ AWS 基本から応用まで

Amazon Web Service マスターコース VPC編

udemyというオンライン学習サイトです。
本を読んだり調べたりしていても、自分の解釈であっているのか、
ふわっとしてることがありますが、
動画で人が話しているのを聞くと認識あってたなーとか確認出来てよかったです。
また、自分が知らなかったサービスやら機能やらが紹介されたりすると、補完的な意味合いでも助かりました。
あ、2倍速でみると時短でいいですよ。意外といけるものです(笑)
★たびたびセール（大幅値引き）をされているみたいなので、安い時に買えばよいかと。

3. より内容の深い、本を読む　←今ここ！

Amazon Web Services 業務システム設計・移行ガイド

業務で使えるような知識を求め、ただいま読書中です！

その他メモ

• udemyについて
  私はオンラインコースは二つとも、1500円程度で買いました。
  クレジット払いはなんとなくやりたくなかったので、スマホにudemyのアプリを入れてスマホ払いで購入。
  家でDLしておけば、電車などで通信なしで動画が見れます。

• AWSアカウントについて
  2段階認証を導入しておいたほうが良いです。
  アカウントをのっとられ、高額請求が。。という記事を見たことがあります。
  https://aws.amazon.com/jp/iam/details/mfa/

• 調べ方について
  ネットで調べたりとか、下記のサイトを見たりしています。
  https://aws.amazon.com/jp/aws-jp-introduction/

はじめて記事を書いてみましたが、こんな感じでいいのかな？という感じです(^^;
メモ的な意味合いも含め記載しますが、参考にされるかがいたら幸いです。

前書き

AWSのTranslateが少し前に日本語に対応しました。
翻訳系もGoogleから少し離れれるのかなぁと思ったぐらいで特に気にしていなかったのですが
AWSのサービスをみていて「Comprehend」というサービスがあるのに気づきました。

--

Amazon Comprehend は、機械学習を使用してテキスト内でインサイトや関係性を検出する自然言語処理 (NLP) サービスです。機械学習の経験は必要ありません。

--

昔から機械学習とかには興味があったのですが、敷居が高く手が出せず。。。
ですが、Comprehendを利用することで簡単に自然言語処理ができます。

単語と単語の関係や、単語の抜き出し、あとは感情分析ができるということです。

ですが、日本語には対応していないらしく...というのを知った際に、 Translateの日本語対応を思い出しました。

というわけで、入力された日本語を英語に変換してそれの感情分析を行うLINE BOTを作ってみました。

構成

ざつですが、ざっくり↓みたいな感じです。

LINE BOTへのメッセージをWebHookでAPI Gatewayが受け取り、Lambda側で
まず、言語を英語へTranslateで変換して、Comporehendへ渡して感情を数値化して、LINE BOTへ返信を行います。

WebHook作成

LINE Developerの設定やLambdaなどの構成については割愛します。

Serverless FrameworkのPythonテンプレートで作成します。

serverless.yaml

Yaml的にはこんな感じです。

service: comprehend-bot

provider:
  name: aws
  runtime: python3.6
  stage: v1
  region: us-east-1

functions:
  bot_hook:
    handler: handler.bot_hook
    events:
     - http:
         path: bot/hook
         method: post
plugins:
  - serverless-python-requirements
custom:
  pythonRequirements:
    dockerizePip: true

iamRoleStatements:
  - Effect: "Allow"
    Action:
      - "dynamodb:*"
      - "comprehend:*"
      - "translate:*"

Comprehendのリージョン的に、東京リージョンだと使えないためバージニアにしています。
特筆事項としては、iamRoleにtranslateとcomprehendを足しています(dynamodbは特に使いませんが、メッセージを保存とかの際に利用できます)

あと、Pythonのline-bot-sdkを使いますので、reruirementsを使用します。

requests==2.18.4
flask
line-bot-sdk

serverlessを利用せずにzipでやる場合は必要ありませんが、serverless-python-requirementsを使う場合はdockerが必要になります。

API実装

Pythonのboto3を使って実装します。
処理の流れ的には、

1. Lineのメッセージを受け取る
2. Translateで英語に翻訳
3. Comprehendで感情を分析
4. Lineへ返す。

みたいな流れです。

ソース的にはこんな感じ

# -*- coding: utf-8 -*-

import os
import sys
import logging
import json
import boto3

from linebot import (
    LineBotApi, WebhookHandler
)
from linebot.exceptions import (
    InvalidSignatureError
)
from linebot.models import (
    MessageEvent, TextMessage, TextSendMessage,
)

# 翻訳
translate = boto3.client('translate')
# 言語処理
comprehend = boto3.client('comprehend')

logger = logging.getLogger()
logger.setLevel(logging.INFO)

LINE_CHANNEL_ACCESS_TOKEN = os.environ["LINE_CHANNEL_ACCESS_TOKEN"]
LINE_CHANNEL_SECRET = os.environ["LINE_CHANNEL_SECRET"]

line_bot_api = LineBotApi(LINE_CHANNEL_ACCESS_TOKEN)
handler = WebhookHandler(LINE_CHANNEL_SECRET)

def bot_hook(event, context):

    line_event = json.loads(event['body'])['events'][0]

    logger.info(line_event)

    # 引数テキストを英語変換
    trans = translate.translate_text(
        Text=line_event['message']['text'],
        SourceLanguageCode='auto',
        TargetLanguageCode='en'
    )

    translatedText = trans['TranslatedText']

    logger.info(translatedText)

    # 感情表現を取得
    detect_sentiment = comprehend.batch_detect_sentiment(
        TextList = [
            translatedText
        ],
        LanguageCode='en'
    )

    logger.info(detect_sentiment)
    logger.info(detect_sentiment['ResultList'][0]['Sentiment'])

    sentiment = detect_sentiment['ResultList'][0]['Sentiment']

    line_bot_api.reply_message(
        line_event['replyToken'],
        TextSendMessage(text=sentiment)
    )

    response = {
        "statusCode": 200
    }

    return response

boto3が便利すぎますね笑

boto3のtranslateとcomprehendで翻訳と感情分析を行います。

comprehendの返り値はこんな感じ

'Sentiment': 'NEGATIVE', 
'SentimentScore': {'Positive': 0.05495094880461693, 'Negative': 0.8831858038902283, 'Neutral': 0.03225637972354889, 'Mixed': 0.02960692159831524}}

非常に面白いです。
Sentimentに入るのが、リクエストされた言葉の感情
SentimentScoreにあるのが、それぞれの感情数値です。

POSITIVE, NEGATIVE, NEUTRAL, MIXED の４つで数値化されます。
その中で一番高いのが、Sentimentに入ります。

そのため、　レスポンスのSentimentをLineへ返すのが、下記の処理です。

    line_bot_api.reply_message(
        line_event['replyToken'],
        TextSendMessage(text=sentiment)
    )

はい。実装は以上です。

デプロイ、動作確認

sls deployでLambdaをデプロイして、API GatewayのパスをLineのWebhookとして設定します。
(すみません。割愛します。)

あとは、LINE BOTに対して、メッセージを送ります。
うまくいけば、こんな感じ。

(今まで喋ることがなかったオリキャラBOTが動きました。)

はい。以上です。
メッセージですが、これだとTHE BOTなので
せっかく、他の感情数値もComprehendがくれているので、下記みたいな感じで　Formatしても面白いですね。

あとがき

正直なところ、これといって使い道がありませんが、
Translateと組み合わせれば、日本語の感情分析もなんとなくできるので
ツイートの分析とか、統計で何か面白い使い道があるかなと思います。

AWSは単一のサービスで見ても面白いですが、さらに夢を広げるために別サービスを利用することの楽しみが
さらに広がった一件でした♪

今回のリポジトリ

Apache PDFBox®とはPDFをゴニョゴニョするためのJavaのオープンソースライブラリです。

AWS LambdaではJava8のランタイムを使えるので、これをAWS Lambda上で動かすこと自体は特に難しいことではないのですがちょっとだけ注意点があったので記事に残します。

注意点

Lambda実行時の仕様として/tmp以外のフォルダは書き込みなどのアクセス権が制限されていますが、PDFBoxのデフォルトの動作としてfont cacheを更新しようとするのでその際にアクセス権の関係でエラーになります。

これを回避するにはpdfbox.fontcacheというシステムプロパティを/tmpにする必要があります。

たとえばLambdaのハンドラー関数実行後、PDFBoxを使う前に

ハンドラー関数

System.setProperty("pdfbox.fontcache", "/tmp");

とすることなどで回避できます。

参考

Apache PDFBox®

前のつづき
https://qiita.com/nannany/items/50a514fa56255811704e
踏み台サーバから接続するインスタンスの作成準備から始める。

bastion経由で操作したいインスタンス(targetインスタンス)作成

targetインスタンスを入れるVPCを整備

1. targetインスタンス用VPC作成

aws ec2 create-vpc --cidr-block 10.2.0.0/16 
aws ec2 create-tags --resources vpc-0ed7b004702d6b31f --tags Key=Name,Value=target_cli

2. targetインスタンス用サブネット作成

aws ec2 create-subnet --vpc-id vpc-0ed7b004702d6b31f --cidr-block 10.2.0.0/24
aws ec2 create-tags --resources subnet-066876581dbfa4f88 --tags Key=Name,Value=target_subnet_cli

targetインスタンス作成(キーペアは前作ったものを使いまわす）

1. 秘密鍵（bastion_cli_key)をmy_bastionに転送

scp -i .ssh/bastion_cli_key.pem  .ssh/bastion_cli_key.pem ec2-user@52.198.210.184:/home/ec2-user

2. 秘密鍵の権限を400にして、.ssh配下におさめる

ssh -i .ssh\bastion_cli_key.pem ec2-user@52.198.210.184
chmod 400 bastion_cli_key.pem 
mv bastion_cli_key.pem .ssh

3. VPCどうしをピアリング接続し、その接続を承諾する

aws ec2 create-vpc-peering-connection --vpc-id vpc-0ed7b004702d6b31f --peer-vpc-id vpc-0074168dfa72a5826
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-094d895104a32cf4a

4. 各VPCのルートテーブルにて、相手のVPCへの通信をピアリング接続に紐づけるようにする

# bastion側のカスタムルートテーブルにピアリング接続へのルートを加える
aws ec2 create-route --route-table-id rtb-0362a010826fc18bc --destination-cidr-block 10.2.0.0/16 --vpc-peering-connection-id pcx-094d895104a32cf4a
# target側のメインルートテーブルにピアリング接続へのルートを加える
aws ec2 create-route --route-table-id rtb-02a9cca2b46dac9a2 --destination-cidr-block 10.1.0.0/16 --vpc-peering-connection-id pcx-094d895104a32cf4a

5. targetインスタンス用セキュリティグループ作成。22と10000番ポートにくるSSHのみ許可

aws ec2 create-security-group --group-name from_bastion_ssh --description "Security group for SSH access from bastion" --vpc-id vpc-0ed7b004702d6b31f
aws ec2 authorize-security-group-ingress --group-id sg-098ded7f7da9bc597 --protocol tcp --port 22 --source-group sg-04fa98bf54b2c3602
aws ec2 authorize-security-group-ingress --group-id sg-098ded7f7da9bc597 --protocol tcp --port 10000 --source-group sg-04fa98bf54b2c3602

6. targetのEC2インスタンス作成。無料枠のAMI（Amazonマシンイメージ）を選択

aws ec2 run-instances --image-id ami-0d7ed3ddb85b521a6 --count 1 --instance-type t2.micro --key-name bastion_cli_key --security-group-ids sg-098ded7f7da9bc597 --subnet-id subnet-066876581dbfa4f88
aws ec2 create-tags --resources i-04b09b50680736f5f --tags Key=Name,Value=my_target

7. bastion経由でtargetインスタンスに接続する

# クライアント端末のpowershellで実行
ssh -i .ssh\bastion_cli_key.pem ec2-user@52.198.210.184
# bastionで実行
ssh -i .ssh/bastion_cli_key.pem ec2-user@10.2.0.78

8. sshd_configを編集

cd /etc/ssh/
# sshd_configを退避 
sudo cp sshd_config sshd_configbk
# sshd_configを編集
sudo vim sshd_config

差分はこんな感じ

< Port 22
---
> Port 10000

9. targetインスタンスを再起動

aws ec2 reboot-instances --instance-ids i-04b09b50680736f5f

10. 22番ポートでは接続できず、10000番ポートで接続できることを確認

[ec2-user@ip-10-1-0-184 ~]$ ssh -p 22 -i .ssh/bastion_cli_key.pem ec2-user@10.2.0.78
ssh: connect to host 10.2.0.78 port 22: Connection refused

[ec2-user@ip-10-1-0-184 ~]$ ssh -i .ssh/bastion_cli_key.pem -p 10000 ec2-user@10.2.0.78
Last login: Sun Jan 27 03:35:37 2019 from 10.1.0.184

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/

11. targetインスタンスに紐づくセキュリティグループから、22番ポートの通信許可を外す

aws ec2 revoke-security-group-ingress --group-id sg-098ded7f7da9bc597 --protocol tcp --port 22 --source-group sg-04fa98bf54b2c3602

これで以下の構成が完成した。

疑問に思った点、つまずいた点

• EC2を起動するコマンドは？→aws ec2 start-instances --instance-ids <instance_id>
• aws ec2 describe-instance-statusだと起動中のインスタンスしか表示されない
• EC2を再起動するコマンドは？→aws ec2 reboot-instances --instance-ids <instance_id>

ここ数年AWSのインフラ設計～構築～運用をやってきましたが、これからAWSを導入してみよう、使ってみようと言う方のために、その知見を少し公開

アカウントの開設

AWSのアカウントの開設の際、クレジットカードが必要です。個人はともかく法人利用の際は導入時にそれなりの障壁となりますので、注意が必要です。NTT東日本のリセールを通してアカウントを開設すればクレカが不要らしいですが、このような請求代行がいくつかあるので、それらを利用するのも良いかもしれません。

https://business.ntt-east.co.jp/service/publiccloud/

利用料金と請求書の確認

AWSは従量課金であるため、使った分だけ請求がきます。テストでちょっとだけ使った仮想サーバを立ち上げっぱなしで放置、退職した社員が作成した今は使ってもいない放置された仮想サーバ、誰がなんのために作ったのかよくわからないインスタンスなどなどを放置していますと、請求料金がガンガン上がっていきます。不要なサーバやデータは削除する、使っていない時は停止するなどまめなリソース管理が必要です。

AWSで使えないアドレス

一般的に端末に割り振りできないネットワークアドレスとブロードキャストアドレス以外にAWSではネットワークアドレスに 1～3 を足した次の３つのIPアドレスが予約アドレスとして使えません。

事例（数値はサンプルで、他のネットワークアドレスでも同等です）

アドレス	説明
10.0.0.0/24	ネットワークアドレス	一般的に使用できない
10.0.0.1/24	仮想ルータ	AWSでは使用できない
10.0.0.2/24	DNSリゾルバ	AWSでは使用できない
10.0.0.3/24	AWS予約	AWSでは使用できない
10.0.0.255/24	ブロードキャストアドレス	一般的に使用できない

Zone Apex が使えない事例

Zone Apexとは、 tanuki.com などサブドメイン抜きのドメイン名そのものをさしますが、よくウェブサーバでホスト名を付けない短いURLで運用されているのを見かけるかと思います。

名前	説明
tanuki.com	Zone Apex
tokyo.tanuki.com	サブドメイン付き

ELB(ロードバランサー)などAWSの一部のサービスは、DNSラウンドロビンで冗長化されていたり、IPアドレスが固定されていなかったりするため、立ち上げたインスタンスはIPアドレスではなくamazon所有ドメインのFQDNを使って利用します。

立ち上げたELBなどのサービスに自社ドメインを対応させて利用する際には、Aレコードではなく、CNAMEレコードで自社ドメインをAmazonから渡されたFQDNに対応させる運用となりますが、DNSの仕様上、Zone Apexの文字列をCNAMEレコードとして登録することができません。

この問題を解決するためにAmazonが独自にカスタマイズしたDNSサービスであるRoute53を利用して、Aliasレコードと呼ばれるAWS独自のレコードで運用すれば自社ドメインのZone ApexとELB等のAmazonから渡されたFQDNを関連付けることができます。しかし、DNSやドメイン運用ポリシー等の問題でRoute53を利用できない場合があります。こういう場合、自社ドメインで短いURLでの運用はあきらめるか、もしくは、リダイレクトなどなんらかの仕組みをかまして実現するしかありません。いずれにしても、フォークリフトですでに短いURLで運用されているサービスをAWSへ上げる場合は注意が必要です。

詳細を知りたい方はRFCを読んでください
https://www.ietf.org/rfc/rfc1912.txt

WorkSpaces の制限

AWSのVDIサービスであるWorkSpacesですが、OSはWindowsではなく、Windows Server OSです。ですので、手持ちのソフトウェアがサーバOSをサポートしておらず、使いたいソフトウェアが利用できないという場合がありますので注意が必要です。また、デフォルトでは英語版が起動するため、日本語パックをインストールしたりOSの言語設定を日本語に変えるなどある程度の作業が発生してしまいます。

Solaris は公開されていない

AWSのセミナーでは x86/amd64 用のOSは自作のOSも含めてすべてAWSで利用できると説明を受けましたが、2019年現在、Oracle Solaris (x86/amd64版)のAMIはラインナップされていません。昔はOpenSolarisが公開されていましたが、今は公開中止となったようです。現状、AWSでSolarisは使えないか、使えたとしても簡単には利用できなさそうです(ライセンス周りやAMIのベース構築など)。

以上、AWSで注意したい点をいくつかピックアップしました。

UdemyのAWSコースの学習ログです。

Udemy コース

手を動かしながら2週間で学ぶ AWS 基本から応用まで
https://www.udemy.com/share/100taiB0EfeFtSRnQ=/

講座の動画を見ながら、料金アラート〜AWS料金の見積もりを学習した。

料金アラート

AWSで発生した料金が指定額まで達した時に、メールで教えてくれる

• CloudWatchで設定する
• AWSの利用料金が〜＄を超えたら通知するよう設定できる

「請求アラートを受け取る」設定する

CloudWatchで料金アラートを設定する手順

請求ダッシュボード＞設定
請求アラートを受け取る をチェックON

CloudWatch＞請求＞アラームの作成
今月の AWS の合計料金がの欄
超過：とりあえず5を入力
通知の送信先：メールアドレスを入力
入力したメールアドレスに確認メールが送信されるので、リンクをクリック
AWS側でメールが確認されるので[確認]をクリック
CloudWatchのメニュー＞アラームがOKになればよい

AWS料金の見積もり方について

２種類ある

• AWS公式＞AWS サービス名 pricingで検索する方法
• Simple Monthly Calculatorを利用（簡易計算機）

AWS公式＞AWS サービス名 pricingで検索する方法

例えばEC2の料金
https://aws.amazon.com/jp/ec2/pricing/
オンデマンドインスタンスの料金を確認する »
リージョン：アジアパシフィック(東京)
表のLinux/UNIX の料金を見る

t3.nanoの月の料金を計算すると 0.0068*24*31=$5.0592 (料金時間日)
t3.nanoは月$5.059、という見積もりができる

Simple Monthly Calculator

https://calculator.s3.amazonaws.com/index.html

リージョンの指定を忘れずに
無料枠の計算の有無を指定できる