Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

トランジットゲートウェイ利用におけるアクセスコントロールについて調べてみました。

$
0
0

こんにちは、技術4課の城です。
先日、東京リージョンにリリースされたトランジットゲートウェイですが、検証していたところ、アタッチメントについてサブネットを指定する部分があり、少し気になりました。
どうやら指定したサブネットにENIが作成されているようで、トランジットゲートウェイでのアクセスコントロールに使えないかと思い、調べてみました。

※本記事に記載の内容は2018/12/19時点での内容となります。

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

AWSドキュメントには下記の記載があり、AZ毎に一つのサブネットを指定する必要があるようです。

For Subnet IDs, select one subnet for each Availability Zone to be used by the transit gateway to route traffic.

トランジットゲートウェイ アタッチメントを作成するとENIが作成される

トランジットゲートウェイとVPCのアタッチする際に指定したサブネットにENIが作成されていました。

aws ec2 describe-network-interfaces \
  --network-interface-ids eni-08a35dc601f9525b3

{
    "NetworkInterfaces": [
        {
            "Ipv6Addresses": [],
            "Description": "Network Interface for Transit Gateway Attachment tgw-attach-0d48f3ef3b8c42603",
            "TagSet": [],
            "Attachment": {
                "DeviceIndex": 1,
                "AttachmentId": "ela-attach-e26232c6",
                "DeleteOnTermination": false,
                "InstanceOwnerId": "amazon-aws",
                "Status": "attached"
            },
            "RequesterId": "942978693842",
            "SourceDestCheck": false,
            "Status": "in-use",
            "SubnetId": "subnet-07c2fbaa545b89e9f",
            "AvailabilityZone": "ap-northeast-1a",
            "PrivateIpAddresses": [
                {
                    "PrivateIpAddress": "172.16.0.46",
                    "Primary": true
                }
            ],
            "Groups": [],
            "InterfaceType": "transit_gateway",
            "PrivateIpAddress": "172.16.0.46",
            "MacAddress": "06:3a:6d:83:50:d4",
            "OwnerId": "************",
            "NetworkInterfaceId": "eni-08a35dc601f9525b3",
            "RequesterManaged": false,
            "VpcId": "vpc-04ff85daf466a2497"
        }
    ]
}

トランジットゲートウェイのアタッチメントに紐づいたENIにセキュリティグループをアタッチして通信制御できるかどうか?

こちらのENIへのセキュリティグループのアタッチはできないようです。
下記のようにセキュリティグループをアタッチしようとしてみましたが、エラーになりました。

aws ec2 modify-network-interface-attribute \
  --network-interface-id eni-08a35dc601f9525b3 \
  --groups sg-0ac1a3070b0924bbd

An error occurred (InternalError) when calling the ModifyNetworkInterfaceAttribute operation (reached max retries: 4): An internal error has occurred

アタッチメントのサブネットのNetwork ACLを利用して通信制御できるか?

ENIが存在するVPC側のCIDRを対象にしたDenyルールについては記載通りアクセス拒否されるのですが、対向側のCIDRを記載したルールについては適用されていないようでした。
トランジットゲートウェイのアタッチメントに紐づいたENIのVPC Flow Logsを確認してみたところ、対向側のIPアドレスは表示されていなかったことから、現時点ではこのような利用方法は難しそうです。
※エッジのEC2のENIで取得したVPC Flow Logsでは送信元が表示されていました。

まとめ

現時点ではトランジットゲートウェイの部分でアクセス制御を行うのは難しそうです。
必要であれば、ルーティング、AWS側であればエッジでのセキュリティグループやNetwork ACL、VPNでオンプレミスに繋ぐのであれば、オンプレミス側のファイアーウォールで適切に設定する必要があるようです。

【参考】
AWS News Blog 「New – Use an AWS Transit Gateway to Simplify Your Network Architecture」
AWSドキュメント
AWS Transit Gateway よくある質問


IAMポリシーでPassRoleするサービスをCloudFormationだけに絞る

$
0
0

こんにちは、PS課のミネです。

IAMユーザーにリソース作成を許可したくない場合、CloudFormation用のIAMロールを作っておき、そのIAMロールをPassRoleする権限だけIAMユーザーには与えておけば、CloudFormation経由でだけリソースを作ることが可能です。

PassRoleするサービスをCloudFormationに絞る

以下のようにiam:PassedToServiceでPassRoleするサービスを絞ることが可能ですが、CloudFormationでスタックを流そうとするとエラーになります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "サービス名.amazonaws.com"
                 }
            }
        }
    ]
}

サポートに確認するとCloudFormationはiam:PassedToServiceに現時点(2018/12/19)では対応していないとのことでした。他のサービスでもiam:PassedToServiceに対応していないものがあるかは不明ですが、ひょっとするとあるかもしれません。
以下のようにポリシーを書くとCloudFormationだけに絞ることが可能です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEqualsIfExists": {
                    "iam:PassedToService": "cloudformation.amazonaws.com"
                }
            }
        }
    ]
}

AD ConnectorでWorkSpacesを利用中、ADのIP変わった時の対処

$
0
0

こんにちは、PS課のミネです。

AD ConnectorでWorkSpacesを展開している場合、ADのIPアドレスが変更となった時、どのような対処がひつようなのでしょうか。

AD Connectorの設定変更だけでは足りない

まずはAD ConnectorのDNSアドレスを変更します。しかし、これだけでは足りません。変更後に作成するWorkSpacesに対しては変更後のDNSアドレスが適用されますが、変更前から存在しているWorkSpacesに対してはDNSアドレスを適用させるため別途設定が必要となります。

WorkSpaces側設定

変更前から存在しているWorkSpacesではレジストリキーを変更する必要があります。

「スタート」ボタンを右クリックし、「ファイル名を指定して実行」を選択。

「regedit」と入力し、「OK」を押下。

「はい」を押下。

バックアップを保存します。レジストリエディターの「ファイル」>「エクスポート」を選択。任意のファイル名で任意の場所へ保存。

「HKEY_LOCAL_MACHINE」>「SOFTWARE」>「Amazon」>「SkyLight」の「DomainJoinDns」をダブルクリック。

値のデータへ新しいDNSアドレスを入力。「OK」を押下。
ここで間違ったDNSアドレスを入力すると正常にログインできなくなる可能性もあります。気を付けましょう。

再起動しDNSアドレスが変更されていればOKです。

BacklogのWikiをGitで管理する仕組みを作ってみた話

$
0
0
こんにちは、技術1課の中村です。
今日の記事はBacklogのWikiをGitで管理する仕組みを作った話です。

本題

サーバーワークスでは業務の標準化や効率化のためのドキュメントをBacklogのWikiにて管理しています。
これまではBacklogのWikiをシンプルに使っていたのですが、BacklogのWikiだと以下の点で物足りなくなってきました。

  • 承認(プルリクエストなど)のような仕組みがない(誰でも更新できてしまう)
  • 長いドキュメントをブラウザ内のテキストボックスで編集するのがつらい
  • 好きなエディタ使って書きたい

上記の点をカバーするためには、ただ単にBacklogのプロジェクトで利用できるGitリポジトリの機能を利用すれば良いのですが、Gitリポジトリを利用しようとすると今度は以下のような点で運用が難しくなってきます。

  • Wikiの機能が使えない
    • ツリービュー
    • ページのタグ
    • 検索
  • 情報までの動線が長い (プロジェクト -> リポジトリ一覧 -> リポジトリ -> ファイル)
  • ページ内に画像を添付できない

そこで、WikiとGitの良いとこどりをするために、BacklogのWikiをGitで管理する仕組みを作ってみました。

つくったもの


Gitにpushすると、リポジトリの最新の状態のものがWikiに反映されます。
そのため、好きなエディタで書き、プルリクの仕組みも使いつつ、情報を閲覧するときはWikiからストレスフリーで見ることができるようになります。便利!

機能

基本は、masterブランチへのPushを検知してBacklogのGitリポジトリ内のmdファイルをWikiに反映させるものなのですが、いくつか機能を持っていますのでここで少し紹介します。

1. ページ間のリンクを相対パスで記載すると、ページ名リンクに書き換える機能

ページ間でリンクを張るときは、ファイルの相対パスで記載できます。そして、相対パスで記載したリンクは、Backlog形式のページリンク記法に書き換えられます。

例)
[リンク](../upperdir/sample.md) -> [[ページ名]]

2. Gitリポジトリ内の画像ファイルを相対パスで参照した形で記載すると、絶対パスに書き換える機能

Gitリポジトリ内の画像ファイルを相対パスで参照した形で記載すると、Wikiで表示できるようにリポジトリ内のファイルを指定する絶対パスに書き換えます。こうすることで、手元のエディタでも、BacklogのWikiでも同じようにドキュメントを見ることができます。(Wikiに画像を添付する必要もありません)

例)
![image](../images/sample.png) -> ![image](https://space.backlog.jp/git/PROJECT/repository/raw/master/xxx/images/sample.png)

3. 相対パス・ファイルの存在チェック機能

上記のリンク生成機能でリポジトリ内のファイルを指定する場合、指定したパスにファイルが存在するかどうかをチェックします。存在しないファイルがパスで指定されている場合、Slackで通知されます。

例)

4. プレビュー作成・削除機能

プルリクを作成すると、 PREVIEW/ブランチ名/ページ名 にて一時的なプレビュー用のページがWikiに作成されます (ブランチ名に / が入る場合はBacklogのWikiで階層化されてしまうため :: に変換されます。)
Gitの差分はBacklogのプルリクの画面で確認できますが、一連の流れを通して確認したい場合や、markdown構文が正しいかどうか、画像が正しい画像に置き換わっているかどうか、など、実際のWikiでページを確認したい時もあります。
プレビュー作成は、こんな時のための機能です。
ちなみに、プレビュー用のページはプルリクがマージ、または却下(クローズ)されると自動で削除されます。
または、プルリクのページにて、以下のようにコメントするとプレビュー用のページを任意に作成、更新、削除できるようになっています。

  • create preview
  • update preview
  • close preview
  • delete preview

まとめ

というわけで、WikiとGitの良いとこどりをした、BacklogのWikiをGitで管理する仕組みの話でした。
ソースコードはGithubにて公開していますので、興味のあるかたはぜひ使ってみてください。
Serverless Frameworkを利用しているので、デプロイ用のS3 Bucketさえ用意しておけばデプロイコマンド一発でデプロイできるようになっています。
https://github.com/serverworks/git2wiki/tree/develop
なお、READMEにも記載していますが、 場合によっては意図せず既存のWikiのページが削除されることがあります。 この仕組を利用する場合は、人手によるWikiの更新を禁止にすることを推奨します。

Cloud AutomatorでWorkSpacesの情報を一覧でダウンロードできるようになりました(β版)

$
0
0

お使いのWorkSpacesの一覧情報を、CSVファイル形式でダウンロード可能な機能が、β版としてCloud Automatorに追加されたのでご紹介致します。
これに伴い、新たに当機能の利用可否をユーザーごとに設定可能な権限も追加されました。
(正式リリースは2019年1月上旬を予定しております)

WorkSpacesリスト作成機能について

AWSのマネージメントコンソール上でご利用中のWorkSpacesの情報を確認するのは、大変な手間がかかります。ご利用台数が多い場合には、全台数を同一ページ上で表示することが出来ず、またタグ情報は1台ずつ展開して表示させる必要があります。

今回 Cloud Automator に追加された「WorkSpacesリスト作成」機能を利用すると、画面上でリスト作成を実行するだけで、お客様の環境にあるWorkSpacesの情報をCSV形式のファイルでダウンロード出来るようになります。当機能をご利用いただくことで、 WorkSpacesの管理負荷を大幅に軽減することが可能となります。

CSVに掲載される情報の以下のとおりです。

  • WorkSpaceのID
  • WorkSpaceのユーザー
  • WorkSpaceバンドルのコンピューティングタイプ
  • WorkSpaceで利用しているバンドルの名前
  • WorkSpaceの実行モード
  • ルートボリュームのサイズ
  • ユーザーボリュームのサイズ
  • ステータス
  • 組織名
  • 前回アクティブだったユーザーの接続日時
  • WorkSpaceに設定されているタグ

ご利用方法

権限の設定
グループメンバーに「インベントリ」という権限が新たに追加されています。これにより、「WorskSpacesリスト作成」機能に対する操作権限を、ユーザーごとに設定可能となっています。

リスト作成
操作権限があるユーザーでログインし、インベントリメニューから行ってください。
今回追加されたアクションのご利用方法は、こちらにマニュアルを用意しております。
マニュアルページ

終わりに

今後のリリース計画については、ロードマップページにて公開しております。
これからもCloud Automatorをよろしくお願いいたします。

Amazon Personalizeつかってみた

$
0
0

こんにちは、PS課のミネです。

今年のre:inventで発表されたAmazon Personalizeとは、パーソナライゼーションやレコメンデーションに関する機械学習の知識がほとんど無くとも、ユーザーがモデルをデプロイできるサービスです。

そんなAmazon Personalizeですがpreviewに当選しましたので、以下のAWS公式ブログ/サンプルを参考にデータセットはRで準備し、AWS CLIでリソースの作成をしてAmazon Personalizeを利用してみたいと思います。

データセット準備

AWS公式ブログでも利用されているMoviLensのratings.csvからデータセットを準備します。AWS公式ブログはPythonで実行されていますが、今回はRで実行してみました。

#CSVファイルを読み込み。
ratings <- read.csv("ratings.csv", header = T)

#rating列をランダムに並べ替えます。もうちょっといい方法はあるかも。
ratings$rating <- sample(ratings$rating, 20000263)

#ratingが4以上の行を抽出。
ratings <- subset(ratings, ratings$rating>3.6)

#rating列の削除。
ratings$rating <- NULL

#Amazon Personalizeで利用できる列名に変更。
colnames(ratings) <- c('USER_ID','ITEM_ID','TIMESTAMP')

#使用する10万件のみ抽出。
ratings <- ratings[1:100000,]

#CSVファイルに保存。row.names = FALSEで行番号を削除しています。
write.csv(ratings, "ratings.processed.csv", row.names = FALSE)

あとはAWS CLIでの作業になります。
S3バケットへアップロードします。

$ aws s3 cp ratings.processed.csv s3://hogehoge

S3バケットのバケットポリシーはPersonalizeからアクセスできるよう以下のようにします。

{
    "Version": "2012-10-17",
    "Id": "PersonalizeS3BucketAccessPolicy",
    "Statement": [
        {
            "Sid": "PersonalizeS3BucketAccessPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "personalize.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::hogehoge",
                "arn:aws:s3:::hogehoge/*"
            ]
        }
    ]
}

AWS CLIでAmazon Personalizeを操作可能にする

Amazon PersonalizeはまだpreviewのためデフォルトではAWS CLIで操作できないようです。
以下を実行して操作可能にします。

$ wget -N https://s3-us-west-2.amazonaws.com/personalize-cli-json-models/personalize.json
$ wget -N https://s3-us-west-2.amazonaws.com/personalize-cli-json-models/personalize-runtime.json
$ aws configure add-model --service-model file://`pwd`/personalize.json --service-name personalize
$ aws configure add-model --service-model file://`pwd`/personalize-runtime.json --service-name personalize-runtime

スキーマ作成

AWS CLIでAmazpn Personalizeが操作できるようになったところで、データセット用にスキーマを作成します。Amazon Personalizeでは事前に定義されたキーワードを使う必要があります。
まずはスキーマをJSONファイル(schema.json)へ書き込みます。

{
    "type": "record",
    "name": "Interactions",
    "namespace": "com.amazonaws.personalize.schema",
    "fields":[
        {
            "name": "ITEM_ID", 
            "type": "string"
        },
        {
            "name": "USER_ID", 
            "type": "string"
        },
        {
            "name": "TIMESTAMP", 
            "type": "long"
        }
    ],
    "version": "1.0"
}

作成したJSONファイルの内容からAMazon Personalizeにスキーマを作成します。

$ aws personalize create-schema --name スキーマ名 --schema file://`pwd`/schema.json

スキーマのARNが返ってくるので以下のコマンドでスキーマの内容を確認できます。

$ aws personalize describe-schema --schema-arn スキーマのARN

データセットグループ作成

データセットグループを作成します。データセットグループとはデータセットやこの後作成するSolution・Campaignをひとまとめにしたものです。

$ aws personalize create-dataset-group --name データセットグループ名

データセットグループのARNが返れば成功です。
続いてデータセットを作成します。

$ aws personalize create-dataset --schema-arn スキーマのARN \
--dataset-group-arn データセットグループのARN \
--dataset-type INTERACTIONS

こちらもデータセットのARNが返ってくれば成功です。

データセットのインポート

先ほどS3へアップロードしたCSVをAmazon Personalizeのデータセットへインポートします。インポートするにはインポートジョブを作成・実行する必要があります。

まずはインポート用のIAMロールを作成します。IAMポリシーは以下とします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::hogehoge"
            ]
        },
        {
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::hogehoge/*"
            ]
        }
    ]
}

IAMロールの信頼関係は以下のようにAmazon Personalizeを指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "personalize.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

作成したIAMロールを使用してインポートジョブを実行します。

$ aws personalize create-dataset-import-job --job-name ジョブ名 \
--role-arn IAMロールのARN \
--dataset-arn データセットのARN \
--data-source dataLocation=s3://hogehoge/ratings.processed.csv

インポートジョブのARNが返ってくるので、以下のコマンドでジョブの実行ステータスが確認できます。latestDatasetImportJobRunstatusがActiveになるとインポート成功です。

$ aws personalize describe-dataset-import-job --dataset-import-job-arn ジョブのARN

Solutionの作成

Amazon Personalizeでは学習アルゴリズムのことをレシピと呼ぶようです。レシピはPersonalizeでデフォルトで用意されているものもありますが、ユーザーが持ち込むことも可能です。インポートしたデータをレシピに学習させたものをSolutionと呼ぶようです。今回のレシピはデフォルトで用意されているDeepFMを利用します。

Solutionの作成は以下のコマンドで実行します。DeepFMのレシピのARNを指定しています。事前定義されたレシピのARNはドキュメントで確認可能です。min-tpsは「minimum transactions per second」の略です。今回は1としておきます。

$ aws personalize create-solution --name Solution名 \
--recipe-arn arn:aws:personalize:::recipe/awspersonalizedeepfmmodel \
--min-tps 1 \
--dataset-group-arn データセットグループのARN

ちなみに上記コマンドでレシピのARNを指定せずに--perform-auto-mlのオプションを使ってAutoMLを利用することができます。AutoMLを利用すればデータセットに対して最適なレシピを選択するのも自動で実行されます。各アルゴリズムに対して知識がなくとも、レシピが選択できるので非常に便利です。

以下のコマンドでSolutionの状態を確認します。latestSolutionVersionstatusがActiveとなれば学習完了です。完了までには少し時間がかかります。

$ aws personalize describe-solution --solution-arn SolutionのARN

Solutionの学習が完了すると、以下のコマンドで各メトリクスが確認できます。

$ aws personalize get-metrics --solution-arn SolutionのARN

Campaignの作成

トレーニングしたSolutionをデプロイしますが、Personalizeでは「Campaign」というコンポーネントでSolutionがデプロイされます。以下のコマンドでCampaignを作成します。--update-modeAUTOを指定していますが、これはSolutionが更新されると自動でCampaignが更新されるというオプションです。MANUALを指定した場合はSolutionを更新しても自動でCampaignは更新されず、aws personalize update-campaignで更新する必要があります。

$ aws personalize create-campaign \ 
--name sample-campaign \ 
--solution-arn SolutionのARN \ 
--update-mode AUTO

レコメンドしてみる

それではレコメンドしてみます。以下のコマンドでレコメンドできます。--query "itemList[*].itemId"でITEM_IDのリストが返ってくるようになっています。

$ aws personalize-runtime get-recommendations \ 
--campaign-arn CampaignのARN \ 
--user-id 任意のUSER_ID \ 
--query "itemList[*].itemId"

以下が返り値の例です。

["4226", "260", "3949", "337", "832", "5459", {略} , "555", "597", "2396"]

まとめ

いかがでしたでしょうか。いとも簡単にレコメンデーションのモデルをデプロイすることが出来ました。今回は事前定義されたレシピを明示的に選択しましたが、AutoMLを有効にするとその選択すらいらなくなります。ほとんど労力をかけずによりよいレコメンデーションの仕組みをアプリケーションに組み込めるわけですね。

Oracle RDSでメモリ使用率が常に高くても心配しなくてよい理由

$
0
0

PS課の杉村です。RDSのメモリ使用率が高くて心配になることはないでしょうか。
たとえRDSのメモリ使用率が80%~90%といった高い水準になっていても、それ自体をあまり心配する必要はない、という内容についてご説明します。

CloudWatchを利用するとRDSの各種パフォーマンス情報を閲覧することができます。
例えばFreeableMemoryメトリクスを見ることで、RDSの使われていないメモリ領域を確認することができます。

Oracle RDSを例にとります。
あるお客様で、Oracle RDSのメモリ使用率が、常時80%~90%くらいの間になっていることがありました。
これについて調べましたので、その結果を書いてみたいと思います。

ポイント

  • RDBMSにおいては常時メモリ使用率が高いことは通常の挙動である
    • Oraleに限らず、RDBMSではストレージへのアクセスを最小化するためにテーブル、インデックス、トランザクション・ログ等をメモリ上にキャッシュする
    • 多くのRDBMSにて、システムで利用可能なメモリの大部分(70~80%前後程度)をキャッシュに割り当てることがベスト・プラクティス
  • Oracle RDSインスタンスはデフォルトで最大87.5%のメモリを使うよう設定されている (r4クラスの場合)
  • その他のOS等のプロセスのメモリ使用率も上乗せされてくるが、RDSでは使用率を圧迫しすぎないようチューニングされている

詳細

以下に根拠となるドキュメントや設定値、理屈について記載してみます。

Oracleでは初期化パラメータのMEMORY_MAX_TARGETおよびMEMORY_TARGETを指定することで自動メモリチューニングがONになり、メモリ領域の自動管理がされます。しかしOracle RDSのパラメータグループではMEMORY_MAX_TARGET/MEMORY_TARGETはいずれもデフォルトで以下の通りです。

IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4})

Huge Pages機能がデフォルトでOFFのインスタンスクラス(m4, m3, r3, t2)では、この値が「DBInstanceClassMemory*3/4」になりますため、インスタンスのメモリ総量の3/4…つまり 75% がOracleが利用するメモリの最大値になります。

※ Huge Pagesとは
m4, m3, r3, t2以外のインスタンスクラスのOracle RDSでは、Huge Pages機能がデフォルトで有効化されています。これはLinux Kernelに仕込まれたメモリ管理を効率化するための仕組みです。

Oracle DB インスタンスで huge pages を使用する
> Oracle 用 Amazon RDS は、データベースの拡張性を増大する Linux Kernel の huge pages をサポートします。Huge pages を使用すると、ページのテーブルを小さくし、メモリ管理の CPU 経過時間を減少することで、大規模なデータベースインスタンスのパフォーマンスを向上できます。詳細については、Oracle ドキュメントの「HugePages の概要」を参照してください。

HugePages
> HugePages is a feature integrated into the Linux kernel 2.6. Enabling HugePages makes it possible for the operating system to support memory pages greater than the default (usually 4 KB). Using very large page sizes can improve system performance by reducing the amount of system resources required to access page table entries.

一方でHuge Pages機能がデフォルトでONのインスタンスクラス(r4, r5, m5など)ではMEMORY_MAX_TARGET/MEMORY_TARGETが0になりこのパラメータを用いる自動メモリ管理が無効化されます。その代わりに別の仕組み(自動PGA/SGA管理)でメモリ管理が行われるようになり、SGA_TARGET, PGA_AGGREGATE_TARGETの二つのパラメータによりメモリ領域の管理が行われます。
以下、それぞれのRDSにおけるデフォルト値です。

sga_target

IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0)

pga_aggregate_target

IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*1/8}, 0)

SGAとPGAを足しますと {DBInstanceClassMemory3/4} + {DBInstanceClassMemory1/8} となりますためインスタンスのメモリ総量の87.5%がOracleが使用する最大値です。

これにプラスしてOSやRDSとしての監視機構のメモリ使用率が上乗せされますが、多くのワークロードで正常に動作するようにAWSによってチューニングされていますので100%に張り付くのでは?という心配はあまりありません。

気を付けるべきこと

これらの理由によって、RDSで常時80%~90%を超えるようなメモリ利用率でも大きな問題とはならない、というわけです。

むしろその内訳…メモリが適切に利用されているかどうかについて、StatspackやAWRなどを利用してチェックすることがより大事になってきます。

またCloudWatchのメトリクスにSwapUsageがあり、スワップの使用量が分かるようになっていますので、そちらも要監視です。
メモリが足りずSwapに落ちるようなことが頻発していれば、インスタンスタイプの変更を検討したほうがよいということになるでしょう。

Serverless Framework で Flask app をデプロイする

$
0
0



はじめに

こんにちは、技術一課の山中です。
本ブログでは Python の Web フレームワークである Flask を AWS に Serverless Framework を用いてデプロイしてみます。
今回は Amazon Linux 2 上で以下に沿って進めます。

Build a Python REST API with Serverless, Lambda, and DynamoDB

Flask とは

Flask は Python 用のマイクロ Web 開発フレームワークです。
標準で提供する機能を最小限にしているため、軽量でマイクロフレームワークと呼ばれています。

事前準備

事前に pyenvpyenv-virtualenv を使って仮想環境を用意しておきます。

$ pyenv virtualenv -p python3.7 3.7.1 flaskenv

また、 Serverless Framework も以下に従いインストールしておきましょう。

$ npm install serverless -g

新しいディレクトリと package.json を作成します。

$ mkdir my-flask-application && cd my-flask-application
$ pyenv local flaskenv
$ npm init -f

今回は以下 2 つのプラグインを利用します。

serverless-wsgi は API Gateway から Lambda へのリクエストを WSGI アプリ用に形式変換してくれるプラグインです。
Flask は WSGI アプリなので WSGI に変換してあげる必要があります。
serverless-python-requirements は自動で requirements.txt に記載した Python 用ライブラリ群をインストールし、パスを読み込んでくれます。

$ npm install --save-dev serverless-wsgi serverless-python-requirements

続いて main.py を作成し以下を記述します。

$ vim main.py
from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello World!"

これはルートパス / にリクエスがくると Hello World! を返すだけの単純な Flask アプリケーションです。
アプリケーションをデプロイするために serverless.yml も作成します。

$ vim serverless.yml
service: serverless-flask

plugins:
  - serverless-python-requirements
  - serverless-wsgi

custom:
  wsgi:
    app: main.app
    packRequirements: false
  pythonRequirements:
    dockerizePip: non-linux

provider:
  name: aws
  runtime: python3.7
  stage: dev
  region: ap-northeast-1

functions:
  app:
    handler: wsgi.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

Lambda ファンクションのハンドラは custom ブロックにある wsgi セクションで指定しています。
今回は main.py の app オブジェクトがエントリーポイントとなっています。

最後に、 Flask パッケージを pip でインストールし、その内容を requirements.txt に出力します。

$ pip install flask
$ pip freeze > requirements.txt

デプロイ

$ sls deploy
Serverless: Generated requirements from /home/ec2-user/my-flask-application/requirements.txt in /home/ec2-user/my-flask-application/.serverless/requirements.txt...
Serverless: Installing requirements from /home/ec2-user/my-flask-application/.serverless/requirements/requirements.txt ...
Serverless: Using Python specified in "runtime": python3.7
Serverless: Packaging Python WSGI handler...
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Injecting required Python packages to package...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (1.32 MB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.................................
Serverless: Stack update finished...
Service Information
service: serverless-flask
stage: dev
region: ap-northeast-1
stack: serverless-flask-dev
api keys:
  None
endpoints:
  ANY - https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev
  ANY - https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/{proxy+}
functions:
  app: serverless-flask-dev-app
layers:
  None

試してみる

ブラウザを開き、 作成された API Gateway のエンドポイントへアクセスしてみましょう。

Hello World! が表示されます!

環境の削除

表示されることを確認したら、以下コマンドを実行しきれいに掃除しましょう。

$ sls remove

おわりに

Flask と Serverless Framework を利用することで簡単に Web アプリケーションを実装することができました。
AWS Lambda を利用しているので DynamoDB や他の AWS サービスと連携することでもっと複雑なアプリケーションも楽に作れそうです!


【SQL Server on EC2】インスタンス間でAlwaysOnを構成する [2.WSFC設定編]

$
0
0

こんにちは。技術4課の伊藤Kです。
AWSエンジニア必携(?)のこのアイテムで美味しくコーヒーをいただいております。

今回は「2台のEC2インスタンス間でSQL Server AlwaysOnを構成する」の第2回、「WSFC設定編」です。
必要なOS設定を完了したインスタンスで、AlwaysOnの基盤となるWSFC(Windows Server Failover Cluster)を設定していきます。

<全3回リンク>
1. OS準備編
2. WSFC設定編 (この記事)
3. AlwaysOn設定編(作成予定)

作業前の状態、前提

・「1. OS準備編」の手順を完了した状態を前提とします。

・作業は「AWS Delegated Administrators」グループに所属させたユーザーアカウントで実施します。

・バージョンエディション、IPアドレス等の情報を再掲します。

OS Windows Server 2012 R2 Standard Edition
SQL Server SQL Server 2014 Enterprise Edition SP2 (12.0.5000.0)
内容 コンピューター名 /
リソース名 /
リスナー名
IPアドレス
AlwaysOn インスタンス #1
(文中「1号機」と記します)
sql01 172.20.10.4
AlwaysOn インスタンス #2
(文中「2号機」と記します)
sql02 172.20.11.4
クラスターコアリソース t-cluster 172.20.10.5 / 172.20.11.5
AlwaysOn リスナー t-aonlis01 172.20.10.6 / 172.20.11.6

機能の追加

1号機にリモートデスクトップでログオンします。サーバーマネージャーの [管理] メニューから [役割と機能の追加] を選択します。

機能と役割の追加ウィザードを進め、 [機能] の項目で [フェールオーバークラスタリング] にチェックを入れて[次へ]をクリックして進めます。そのまま機能の追加を行います。
(自動的に追加される管理ツールについても追加します)

2号機にログオンし、同じ手順で [フェールオーバークラスタリング] の機能を追加します。

フェールオーバークラスターの構成

1号機でサーバーマネージャーの [ツール] メニューから [フェールオーバークラスターマネージャー] を開きます。(2号機で作業してもOKです)

[フェールオーバークラスターマネージャー] で [構成の検証] をクリックします。

ウィザードが開始されます。[次へ]をクリックします。

[名前の入力] に1号機のコンピューター名(FQDN)を入力し、[追加]をクリックすると [選択済みサーバー] へ移動されます。

2号機のコンピューター名も同じ手順で [選択済みサーバー] へ登録します。[次へ]をクリックします。

[すべてのテストを実行する] を選択して、[次へ]をクリックします。

内容を確認して[次へ]をクリックします。

検証が完了します。致命的なエラーが発生しなければ、 [検証されたノードを使用してクラスターを今すぐ作成する] にチェックを入れて、[完了]をクリックすることで、自動的に [クラスターの作成ウィザード] に移動します。

ウィザードが開始されます。[次へ]をクリックします。

[クラスター名] にクラスターコアリソースのリソース名を入力します。下の欄にはクラスターのIPアドレスを入力します。マルチサブネット構成のため、各サブネットから1つずつIPアドレスが必要となります。ここでは上記表に沿って入力します。[次へ]をクリックします。

[使用可能な記憶域をすべてクラスターに追加する] のチェックを外し、[次へ]をクリックします。

「新しいクラスターを作成しています」の画面が表示された後、[概要]画面が表示されます。[完了]をクリックします。

コアリソースのノード間移動確認

「フェールオーバークラスターマネージャー」で作成されたクラスター名をクリックします。

[クラスターコアリソース] のペインで、2つあるIPアドレスのうち、どちらかがオンライン、もう一方がオフラインであることを確認します。

右ペインの[他のアクション] を選択し、メニューから [コアクラスターリソースの移動] → [ノードの選択] を選択します。

[クラスターノード] に表示されるコンピューターを選択して、[OK]をクリックします。

[クラスターコアリソース] のオンラインとオフラインのIPアドレスが入れ替わっていれば成功です。

同じ手順を再度実施し、元あったノードへコアリソースを移動します。(戻りの移動を確認)

OUへの権限設定

クラスターリソースのコンピューターオブジェクトが作成されたOUに対し、コンピューターオブジェクト追加の権限を付与します。

AD管理ツールの「Active Directory ユーザーとコンピューター」を開きます。

表示メニューの拡張機能を選択します。左ペインに表示される項目が増加します。

ドメイン名の最終レベル名のOUが作成されており、展開すると「Computers」OUがあるので右クリックし、 [プロパティ] を選択します。「AWS Managed Microsoft AD」ではデフォルトではこのOUにコンピューターオブジェクトが作成されていきます。

プロパティ画面で[詳細設定]をクリックします。

セキュリティの詳細画面で[追加]をクリックします。

アクセス許可エントリ画面で[プリンシパルの選択]をクリックします。

デフォルトではコンピューターオブジェクトが選択できないので、[オブジェクトの種類]をクリックして、[コンピューター]にチェックを入れてからクラスターコアリソースのコンピューター名を入力して[OK]をクリックします。

[コンピューター オブジェクトの作成]にチェックを入れて[OK]をクリックします。

「特殊」と「コンピューターオブジェクトの作成」が追加されたことを確認し、[OK]をクリックして詳細設定画面、プロパティ画面を閉じます。

ここまで確認できたら、WSFCの設定は完了です。「3.AlwaysOn設定編」へ続きます。

ワンポイント

OS準備の際に「IPアドレスをOS上で設定」した理由について説明します。
OSから設定しない場合、EC2の設定では固定のIPアドレスを割り振っていても、「フェールオーバークラスターの構成ウィザード」の中で、クラスターのIPアドレスが強制的にDHCPからの割り振りとなります。OSからDHCPサーバーが認識できないため割り当てが不可となり、設定に失敗します。
それを避け、あらかじめ用意したIPアドレスを手動で設定させるために、「IPアドレスをOS上で設定」しています。

おわりに

別の記事に記載した通り、セキュリティグループに不備があると、主に「構成の検証」ウィザード内、サーバーの追加画面で[追加]をクリックした際にタイムアウトを起こす現象で先へ進めなくなります。原因がなかなか分からずに時間がかかりました・・・。

新しくなった “AWS Architecture Icons”の利用ガイドラインを読んでみる

$
0
0

2018年10月09日をもって、新しいAWSのアイコンセットがリリースされました。

配布はこちらから: AWS シンプルアイコン

デザインが一新され、かなり様変わりしましたね。よりシャープな感じになったような。利用ガイドラインの定義があるようですので、とりあえず文言を雑に和訳してみました。英文に免疫のない方や、取扱説明書を読まずに始めちゃうタイプの御仁に向けたものとご理解いだたけると助かります(どちらも私のことですが)。

全体

  • AWS Architecture Icons という名前に改名された
  • サービスアイコンだけでなく、図の構成要素(矢印とか)も含まれるようになった
  • 白い背景向けのアイコンと、暗い背景向けのアイコンが定義されている

要素 (System elements)

用語の定義です。

  • Groups (e.g subnet)
  • Arrows
  • Illustrations (e.g Client PC)
  • Product Icons (e.g Amazon EC2)
  • Resource Icons (e.g instances)
  • General resources (e.g internet)

Groups

「VPCの中のサブネット」のようにGroupをネストする場合は、内側のグループから見て0.2インチ(5.08cm)のバッファを持たせる必要があります。

プリセットのGroupでニーズを満たせない場合は “Generic group” を利用してください。ユーザーが勝手に独自のGroupアイコンを作って、作図していはいけません。

Icons

  • プロダクトアイコンをトリミングすることは禁止
  • アイコンの反転・回転は禁止
  • 暗い背景向けのアイコンを使用する場合は、アイコン名称のテキストカラーを変更することができる

Arrows

  • 使いたい形状がプリセットになかった場合は、デフォルトの矢印を使用すること
  • 対角線(斜線)で作図してはいけない
  • プリセット、もしくはデフォルト以外の矢印を使用してはいけない
  • 矢印が途中で直角に折れるのはOK

補足

(1) あくまで作図のマナーであり、法的な利用規約を含むものではありません。別途ご確認ください。

(2) この記事の記載は、2019年1月時点のガイドラインに基づくものです。予めご了承ください。

おわりに

旧アイコン(Simple Icon)の今後の扱いについては、pptxの中で特に言及はありませんでした。このまま古いアイコンを使っていても当面の問題はなさそうですが、今後のメンテナンスがいつまで保証されるかは不明ですので、早めに乗り換えておいた方が良さそうですね。

ルールの中身を見る限りでは、神経質になるほどの厳しいものではなさそうです。気楽に使っていきましょう。

Zappa で Django をデプロイする

$
0
0



はじめに

Python の Web フレームワークである Django を AWS に Zappa を用いてデプロイします。
今回は Amazon Linux 2 上で Guide to using Django with Zappa に沿って進めてみます。

Django とは

Django とは、 Python 用の Web フレームワークの中で最も人気のあるフレームワークの 1 つです。
Flask と違い、Django は Web アプリケーションの実装に必要となると予測される多くの機能の提供してくれるフルスタックフレームワークです。

環境のセットアップ

Setup your Environment – Guide to using Django with Zappa に従い、環境のセットアップを行います。
本ブログでは pyenvpyenv-virtualenv を使って仮想環境を用意します。
※ Zappa が Python の 3.7 系ではまだ利用できないため今回は 3.6 系で環境を作成します。

$ pyenv virtualenv 3.6.6 djangoenv

続いて、ディレクトリを作成し Django と Zappa をインストールします。

$ mkdir zappatest && cd zappatest
$ pyenv local djangoenv
$ pip install django zappa

※もしインストール中に UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2339: ordinal not in range(128) のエラーが発生した場合は、以下を実行後再度インストールを行ってください。

$ export LANG=en_US.UTF-8 LANGUAGE=en_US.en LC_ALL=en_US.UTF-8

Django のセットアップ

Core Django Setup – Guide to using Django with Zappa に従い、 Django のセットアップを行います。

IAM 権限の設定

Minimum AWS policies for example. を参考に必要な権限を持った IAM Role をデプロイ用インスタンスにアタッチします。

Django プロジェクトの作成

デモ用 Django プロジェクト frankie を作成します。

$ django-admin startproject frankie .

実際に動かしてテストしてみましょう。
以下を実行して、ブラウザから http://[EC2 の IP アドレス]:8000 にアクセスしてください。

$ python manage.py runserver 0.0.0.0:8000

以下のような画面がでるはずです。

Django が持つセキュリティ機能によってアクセスが弾かれているので frankie/settings.pyALLOWED_HOSTS に EC2 の IP アドレスを追加して上げる必要があります。
詳しい内容は Security in Django | Django documentation | Django を見てみてください。

$ vim frankie/settings.py
...
ALLOWED_HOSTS = [ "xx.xx.xx.xx" ]
...

修正後にもう一度 runserver を実行しブラウザにアクセスすると以下画面が表示されるはずです。

Zappa のセットアップ

デフォルトのリージョンを指定していない場合は、先に以下を実行しデフォルトリージョンの設定を行ってください。

$ aws configure --profile zappa
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: ap-northeast-1
Default output format [None]:
$ cat ~/.aws/config
[profile zappa]
region = ap-northeast-1

続いて以下に従い、 Zappa のセットアップを行います。

$ zappa init

███████╗ █████╗ ██████╗ ██████╗  █████╗
╚══███╔╝██╔══██╗██╔══██╗██╔══██╗██╔══██╗
  ███╔╝ ███████║██████╔╝██████╔╝███████║
 ███╔╝  ██╔══██║██╔═══╝ ██╔═══╝ ██╔══██║
███████╗██║  ██║██║     ██║     ██║  ██║
╚══════╝╚═╝  ╚═╝╚═╝     ╚═╝     ╚═╝  ╚═╝

Welcome to Zappa!

Zappa is a system for running server-less Python web applications on AWS Lambda and AWS API Gateway.
This `init` command will help you create and configure your new Zappa deployment.
Let's get started!

Your Zappa configuration can support multiple production stages, like 'dev', 'staging', and 'production'.
What do you want to call this environment (default 'dev'): # デフォルトでよいのでなにも入力せずエンター

AWS Lambda and API Gateway are only available in certain regions. Let's check to make sure you have a profile set up in one that will work.
Okay, using profile zappa!

Your Zappa deployments will need to be uploaded to a private S3 bucket.
If you don't have a bucket yet, we'll create one for you too.
What do you want to call your bucket? (default 'zappa-7o1fjyn6x'): zappa-bucket # デプロイ用の S3 バケットがある場合はバケット名を指定

It looks like this is a Django application!
What is the module path to your projects's Django settings?
We discovered: frankie.settings
Where are your project's settings? (default 'frankie.settings'): # Zappa が自動的に Django の設定ファイルを見つけてくれるのでそのままエンター

You can optionally deploy to all available regions in order to provide fast global service.
If you are using Zappa for the first time, you probably don't want to do this!
Would you like to deploy this application globally? (default 'n') [y/n/(p)rimary]: # グローバルにデプロイはしないのでそのままエンター


Okay, here's your zappa_settings.json:

{
    "dev": {
        "aws_region": "ap-northeast-1",
        "django_settings": "frankie.settings",
        "profile_name": "zappa",
        "project_name": "zappatest",
        "runtime": "python3.6",
        "s3_bucket": "swx-zappa-ap-northeast-1"
    }
}

Does this look okay? (default 'y') [y/n]: # 確認して問題なければそのままエンター


Done! Now you can deploy your Zappa application by executing:

        $ zappa deploy dev

After that, you can update your application code with:

        $ zappa update dev

To learn more, check out our project page on GitHub here: https://github.com/Miserlou/Zappa
and stop by our Slack channel here: https://slack.zappa.io

Enjoy!,
 ~ Team Zappa!

デプロイ

Zappa でデプロイしてみましょう。
自動的に Lambda 上で稼働する Django プロジェクトへ HTTP リクエストを送るための API Gateway を作成してくれます。

$ zappa deploy dev
Calling deploy for stage dev..
Creating zappatest-dev-ZappaLambdaExecutionRole IAM Role..
Creating zappa-permissions policy on zappatest-dev-ZappaLambdaExecutionRole IAM Role.
Downloading and installing dependencies..
 - sqlite==python36: Using precompiled lambda package
Packaging project as zip.
Uploading zappatest-dev-1547095386.zip (14.4MiB)..
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 15.1M/15.1M [00:00&lt;00:00, 29.7MB/s]
Scheduling..
Scheduled zappatest-dev-zappa-keep-warm-handler.keep_warm_callback with expression rate(4 minutes)!
Uploading zappatest-dev-template-1547095398.json (1.6KiB)..
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1.63K/1.63K [00:00&lt;00:00, 47.6KB/s]
Waiting for stack zappatest-dev to create (this can take a bit)..
 75%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████                                           | 3/4 [00:09&lt;00:04,  4.81s/res]
Deploying API Gateway..
Deployment complete!: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev

作成されたエンドポイント https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev へブラウザからアクセスしてみると、

前回同様アクセスできないので、 xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com を追加し再デプロイします。

$ vim frankie/settings.py
…
ALLOWED_HOSTS = [ 'xx.xx.xx.xx', 'xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com' ]
…

修正後に内容を反映させるため update コマンドを実行します。

$ zappa update dev
Calling update for stage dev..
Downloading and installing dependencies..
 - sqlite==python36: Using precompiled lambda package
Packaging project as zip.
Uploading zappatest-dev-1547096673.zip (14.4MiB)..
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 15.1M/15.1M [00:00&lt;00:00, 8.51MB/s]
Updating Lambda function code..
Updating Lambda function configuration..
Uploading zappatest-dev-template-1547096683.json (1.6KiB)..
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1.63K/1.63K [00:00&lt;00:00, 47.1KB/s]
Deploying API Gateway..
Scheduling..
Unscheduled zappatest-dev-zappa-keep-warm-handler.keep_warm_callback.
Scheduled zappatest-dev-zappa-keep-warm-handler.keep_warm_callback with expression rate(4 minutes)!
Your updated Zappa deployment is live!: https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev

もう一度 https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev へアクセスすると以下画面が表示されるはずです。

この 404 レスポンスは Django アプリケーションが正しく動いていることを示しています。

静的ファイルのホスティング

Hosting Static Files – Guide to using Django with Zappa に従い、 Django で提供されている静的ファイルを S3 に配置しホスティングを行っていきます。

S3 のセットアップ

バケットの作成

今回は S3 に静的ファイルを配置しホスティングを行うため、ホスティング用のバケットを作成してください。
本ブログ上ではバケット名を zappa-static とします。

CORS の設定

Lambda から S3 のオブジェクトへクロスオリジンアクセスを可能にするために CORS の設定を行います。
バケットの設定から Permissions タブを選び、 CORS configuration ボタンをクリックし以下を入力します。
※今回はサンプルとしてシンプルな設定にしていますが、実際の本番環境等で利用する際はスコープを狭めるなど考慮が必要です。

<CORSConfiguration>
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>Authorization</AllowedHeader>
</CORSRule>
</CORSConfiguration>

パブリックアクセス設定の変更

バケットの設定から Permissions タブを選び、 Manage public access control lists の項目を以下のように False に変更します。

Django プロジェクトの設定

まず、静的ファイルを S3 とやり取りするために django-s3-storage をインストールします。

$ pip install django-s3-storage
$ pip freeze | grep django-s3-storage
django-s3-storage==0.12.4

次に、 settings.pyDjango-S3-Storage を追加します。

$ vim frankie/settings.py
…
INSTALLED_APPS = [
     …
     'django_s3_storage',
]
…

更に末尾に Django-S3-Storage の設定を追加します。

# STATIC_URL = '/static/'
YOUR_S3_BUCKET = "zappa-static" # ホスティング用バケットのバケット名を入力

STATICFILES_STORAGE = "django_s3_storage.storage.StaticS3Storage"
AWS_S3_BUCKET_NAME_STATIC = YOUR_S3_BUCKET

# These next two lines will serve the static files directly
# from the s3 bucket
AWS_S3_CUSTOM_DOMAIN = '%s.s3.amazonaws.com' % YOUR_S3_BUCKET
STATIC_URL = "https://%s/" % AWS_S3_CUSTOM_DOMAIN

# OR...if you create a fancy custom domain for your static files use:
#AWS_S3_PUBLIC_URL_STATIC = "https://static.zappaguide.com/"

静的ファイルを S3 へ配置します。

$ zappa update dev
$ zappa manage dev "collectstatic --noinput"

アクセスしてみる

早速アクセスしてみましょう!
ブラウザを開き、 https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/admin にアクセスしてみてください、以下が表示され S3 に配置した CSS ファイルが読み込まれています!

おわりに

今回はドキュメントに沿って、 Django を Zappa でデプロイする手順をまとめてみました。(まだまだやることはありますが…
手順は多いですが、これならサクサク作れそうですね!

【社内勉強会】『機械学習を始める前の「学習」』を発表しました

$
0
0

こんにちは、技術4課の多田です。

先日、機械学習の基礎的な内容をテーマにした社内勉強会を開催したので、資料を公開します。

去年からAIの分野に興味をもって機械学習やディープラーニングを0から勉強し始めました。

最近機械学習の実践としてJupyter Notebookを使ってscikit-learnやnumpy、matplotlibなどのライブラリを活用したデータの解析やモデル生成の勉強がようやくわかってきました。

機械学習に興味があっても、いきなり実践をやってしまうといろんな専門用語、ツール等がわからず、勉強してて辛かった過去の経験から実践に入る前段の情報を伝えたいと思って資料を作りました。

資料

資料はこちらです。

まとめ

今回は、機械学習を実践する前の導入の話をしたのですが、次は実践のプログラミングを行いながら、機械学習を体感してもらえる内容にしていきたいです。

AWS IoTのLambda呼び出しアクションを検証してみた

$
0
0
こんにちは、技術1課の中村です。
今日は、AWS IoTのRule Actionについてのお話です。
AWS IoTのRule Actionといえば、S3やSQS、DynamoDB、さらには SalesforceなどのSaaSとの連携もこなしてくれる、すごいヤツです。
今回は、AWS IoTのRule Actionの中のLambda呼び出しアクションについて検証をしてみました。

本題

今回ここで書くことは以下の3つです。

  1. AWS IoTのRule ActionによるLambda Functionの起動は、同期タイプ?非同期タイプ?
  2. AWS IoTのRule ActionでLambda Functionを指定した場合、Error Actionはどのような条件で実行される?
  3. AWS IoTからLambda Functionを起動したい時、結局の所どうすべき?(筆者の視点から)

では、早速進めていきましょう。

1. AWS IoTのRule ActionはによるLambda Functionの起動は、同期タイプ?非同期タイプ?

結論から言うと、非同期タイプでした。
まずは、Lambdaの サポートされているイベントソース のページを確認してみたのですが、AWS IoTからの実行についての記載はなかったので実際に試してみることにしました。

Lambdaは、同期タイプと非同期タイプで異常終了時の再試行の挙動が異なります。具体的には、同期タイプの呼び出しの場合は異常終了したとしても再試行は行われません。対して、非同期タイプの呼び出しの場合は異常終了した時、その後間隔を空けて2回Lambdaによって再試行が行われます。

そのため、AWS IoTから連携するLambda Functionに意図的にエラーを仕込んで、Lambdaによって再試行されるかどうかを試してみました。結果、元々の実行が1回、その後Lambdaによって2回再実行されていることが確認できたので、非同期タイプの呼び出しであると言えるでしょう。

…と、もっともらしく検証の方法を書いたのですが、シンプルにCloudTrailを見れば良いという事に後から気がつきました。
というわけでCloudTrailから確認してみました。以下は抜粋ですが、ちゃんと "invocationType":"Event" (非同期呼び出し) となっていますね。
(同期呼び出しの場合は、 "invocationType":"RequestResponse" となります)

eventtime eventsource eventname useragent requestparameters(抜粋)
2019-01-24T05:20:38Z lambda.amazonaws.com Invoke iot.amazonaws.com “functionName”:”invoke_test”
“invocationType”:”Event”
2019-01-24T05:20:38Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test”
2019-01-24T05:21:41Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test” (リトライ)
2019-01-24T05:23:38Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test” (リトライ)

2. AWS IoTのRule ActionでLambda Functionを指定した場合、Error Actionはどのような条件で実行される?

これも結論から言うと、恐らく「AWS IoTからLambdaのInvoke APIの実行に失敗した時に、Error Actionが実行される」だと考えられます。
1 で記載した通り、AWS IoTからのLambda Functionの呼び出しは非同期です。そのため、Lambda Functionの呼び出しが成功したかどうかはステータスコード(202)で返りますが、Lambda Functionの中身のプログラムが正しく終了したかどうかは呼び出し時には受け取ることはできません。

こちらも検証してみました。

パターン1


前提

  • AWS IoTのRule ActionにLambda Function Aの呼び出しを、Error ActionにLambda Function Bの呼び出しを設定する
  • Lambda Function A には意図的にエラーを仕込んで、プログラムが必ず異常終了するように設定する
  • Lambda Function B は正常終了するように設定する

上記の前提で、Rule Actionで設定したTopicに、メッセージを1通投げてみます。

結果

  • Lambda Function A は計3回実行される (1回の通常実行 + 2回の自動リトライ)
  • Lambda Function B は実行されない
eventtime eventsource eventname useragent requestparameters(抜粋)
2019-01-24T05:20:38Z lambda.amazonaws.com Invoke iot.amazonaws.com “functionName”:”invoke_test” (A)
“invocationType”:”Event”
2019-01-24T05:20:38Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test” (A)
2019-01-24T05:21:41Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test” (Aのリトライ)
2019-01-24T05:23:38Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_test” (Aのリトライ)

パターン2


前提

  • AWS IoTのRule ActionにLambda Function Aの呼び出しを、Error ActionにLambda Function Bの呼び出しを設定する
  • Lambda Function A を削除する
  • Lambda Function B は正常終了するように設定する

上記の前提で、Rule Actionで設定したTopicに、メッセージを1通投げてみます。

結果

  • Lambda Function A 実行されない (そもそも存在しない)
  • Lambda Function B が1回実行される
eventtime eventsource eventname useragent requestparameters(抜粋)
2019-01-24T01:44:47Z lambda.amazonaws.com Invoke iot.amazonaws.com “functionName”:”invoke_failed_test” (B)
“invocationType”:”Event”
2019-01-24T01:44:47Z lambda.amazonaws.com InvokeExecution lambda.amazonaws.com “functionName”:”invoke_failed_test” (B)

(Lambda Function Aの実行ログはCloudTrailには記録されていませんでした)


上記の結果から、「AWS IoTからLambdaのInvoke APIの実行に失敗した時に、Error Actionが実行される」で間違いなさそうです。
パターン1はプログラムのバグによりLambda Function Aが異常終了するケース、パターン2はLambda Functionが存在しないことにより、そもそものLambda Functionの実行( invoke() )に失敗するケースです。

つまり、AWS IoTからRule Actionを使ってLambdaに連携する場合には、連携するLambda Functionにバグがあって異常終了したとしてもRuleに設定したError Actionは実行されないのです。そのため、Lambda Functionの異常終了を拾いたい場合は、Lambdaのデッドレターキューを使ったり、ログ監視をしたり、プログラム内に例外発生時の通知を実装するなり、工夫する必要がありそうですね。

3. AWS IoTからLambda Functionを起動したい時、結局の所どうすべき?(筆者の視点から)

これも結論から書くと、私はAWS IoTとLambdaの間にKinesis StreamsやSQS(SNS)を挟む構成を検討することが多いです。(ここでは、エラーアクションについては割愛します)


AWS IoTのRule Actionを使ってLambdaと直接連携する方法は、データ処理効率の点から個人的にはあまりオススメできません。
一般的にIoTのシステムは継続的に大量のメッセージが流れ込みますが、AWS IoTとLambdaを直で連携させる場合、以下のような懸念点がでてきます。

そもそものデータ流入量が少ないなどで、上記懸念点が気にならないのであれば問題ありませんが、少しでも気になる場合は、Kinesis StreamsやSQSを挟むと少し緩和できます。
これらのサービスを挟むことによる得られるメリットは以下の通りです。

…というわけで、AWS IoTからLambda Functionを起動したい時は、システムの規模・要件に応じて組み合わせるサービスを選べばよいのではないでしょうか。
(AWS IoTとLambdaの直連携も、シンプルでいいですよ!)

まとめ

この記事では、AWS IoTとLambdaの関係について、以下の3つを記載しました。

  1. AWS IoTのRule ActionはによるLambda Functionの起動は、同期タイプ?非同期タイプ?
    -> 非同期タイプ
  2. AWS IoTのRule ActionでLambda Functionを指定した場合、Error Actionはどのような条件で実行される?
    -> invoke() の実行に失敗した時。 invoke() 自体が成功した後にプログラムでコケた場合にはError Actionが呼ばれないので注意
  3. AWS IoTからLambda Functionを起動したい時、結局の所どうすべき?(筆者の視点から)
    -> 規模に応じて、Kinesis StreamsやSQSを挟むと幸せになれる。データ流入量が少ないのであれば直連携でも良さそう

AWSの構成は各種サービスの特徴を理解しながら組み立てていきましょう!

【社内勉強会】『WAF勉強会』

$
0
0

技術4課の渡辺です。
社内でWAF勉強会を行ったので、その時の資料を公開します。
私の最近の担当した案件を元にしていますので、AWS WAFとImperva Incapsulaを例にしています。

資料

助けて!Amazon Connect で設定した覚えがないメッセージが読み上げられるの

$
0
0
Amazon Connect を試してみたけど簡単にインスタンスの構築ができて、コールフローの定義もGUIで簡単に設定できるし楽勝だね!
というレベルを超えたあとにぶつかるあるある問題。
 
発信や受信をしたときにConnectがなにか勝手にしゃべってるんだけどどうなってるの?
設定した問い合わせフローにはそんなの入れてないよ〜。
 
本エントリーでは、設定していないつもりでもいつのまにか利用をしている
Amazon Connect の Defaultフローの種類と設定
についてまとめます。
 

問い合わせフローには複数のTypeが存在しています。
通常利用するのは「問い合わせフロー (インバウンド)」です。
これ以外に8種類のTypeのフローが用意されています。
No Type(問い合わせフロー種類) デフォルトフロー名
1 顧客キューフロー Default customer queue
2 顧客保留フロー Default customer hold
3 顧客ウィスパーフロー Default customer whisper
4 アウトバウンドウィスパーフロー Default outbound
5 エージェント保留フロー Default agent hold
6 エージェントウィスパーフロー Default agent whisper
7 エージェントへの転送フロー Default agent transfer
8 キューへの転送フロー Default queue transfer
以下公式ドキュメントでは「テンプレートの種類」で説明されています。
 
問い合わせフローの中で明示的に設定をしなければ、デフォルトのフローが適用されます。
例えば、キューに入ったお客様がエージェントにつながったときには
顧客キューフロー(Default customer queue)
が利用されます。
 
顧客キューフロー(Default customer queue)では
Thank you for calling. Your call is very important to us and will be answered in the order it was received.
というテキストが読み上げられるように設定されています。
つまりなにも設定変更しなければ、すべてのお客様に勝手に上記のメッセージが流れることになります。
日本で利用する場合このままだと違和感がある、というかまず電話を切られちゃいそうですよね。
 
自分で用意しなくても動く Default のフローを正しく把握して、必要に応じた設定をしていきましょう。
3つの優先度レベルでDefaultフローの初期設定および推奨する設定変更を説明します。
 

優先度:Hight(設定変更を推奨)

【顧客向け設定】顧客キューフロー(Default customer queue)

デフォルトの処理内容 変更検討内容
1. プロンプトのループ
1-1. Text to Speech
Thank you for calling. Your call is very important to us and will be answered in the order it was received.
1-2. Audio recording
Music_Pop_ThisAndThatIsLife_Inst.wav
1-1. キューにはいったタイミングでメッセージの読み上げが不要であれば削除
必要であればメッセージを変更する
1-2. エージェントにつながるまでに流す音楽を必要に応じて変更する

【顧客向け設定】アウトバウンドウィスパーフロー(Default outbound)

デフォルトの処理内容 変更検討内容
1. 通話記録動作の設定
1-1. なし
2. プロンプトの再生
2-1. テキスト読み上げ機能 (アドホック)
This call is not being recorded.
1-1. エージェント AND 顧客 (通話録音有効化)する
2-1.アウトバウンドで顧客にメッセージを読み上げる必要がない場合は削除
顧客に聞かせるメッセージがあれば変更する

 

優先度:Middle(お好みに応じて設定変更)

【顧客向け設定】顧客保留フロー(Default customer hold)

デフォルトの処理内容 変更検討内容
1. プロンプトのループ
1-1. Audio recording
Music_Jass_MyTimetoFly_Inst.wav
1-1. 保留中に流す音楽を必要に応じて変更する

【顧客向け設定】顧客ウィスパーフロー(Default customer whisper)

デフォルトの処理内容 変更検討内容
1. プロンプトの再生
1-1. オーディオを再生します
Beep.wav
1-1.エージェントにつながったタイミングで鳴るBeep音が不要であれば削除
顧客に聞かせる音楽、メッセージがあれば変更する

【エージェント向け設定】エージェント保留フロー(Default agent hold)

デフォルトの処理内容 変更検討内容
1. プロンプトのループ
1-1. Text to Speech
<speak>You are on hold <break time=”10s”/></speak>
※エージェントへ10秒毎にメッセージを繰り返し読み上げる
1-1. 保留中に定期的にメッセージの読み上げが不要であれば削除
必要であればメッセージを変更する

【エージェント向け設定】エージェントウィスパーフロー(Default agent whisper)

デフォルトの処理内容 変更検討内容
1. プロンプトの再生
1-1. テキスト読み上げ機能 (アドホック)
$.Queue.Name
※キューの名前を読み上げる
1-1. エージェントが応答したタイミングでキューの読み上げが不要であれば削除
必要であればそのまま、または別の読み上げる情報を設定する

優先度:Low(必要な場合は設定変更)

以下のフローはクイック接続で転送設定をする場合に利用します。
クイック接続および対応するキューで利用設定が別途必要になります。

【エージェント向け設定】エージェントへの転送フロー(Default agent transfer)

デフォルトの処理内容 変更検討内容
1. プロンプトの再生
1-1. テキスト読み上げ機能 (アドホック)
Transferring now…
1-1. エージェント間で転送した際に読み上げるメッセージ
必要に応じて設定を変更する

 

【顧客向け設定】キューへの転送フロー(Default queue transfer)

デフォルトの処理内容 変更検討内容
1. オペレーション時間の確認
2. 人員の確認
それぞれの条件でメッセージを読み上げ
  • We are currently out of hours. Goodbye.
  • There are currently no agents staffed. Goodbye.
  • Failed to transfer to queue. Goodbye.
  • Now transferring your call.
利用する場合はフローの設計と要件に応じた設定を推奨

 

共通の注意事項

  • 日本語でメッセージを読み上げる場合は、読み上げる処理の前に「音声の設定」で日本語の音声(Mizuki または Takumi)を設定してください
    • 設定し忘れるとメッセージの読み上げができません(実行結果は無音になります)
  • 上記の情報は2019-01-28時点の情報です
    • インスタンスを構築したタイミングでの記載の設定内容と異なる可能性があります。

参考情報:プロンプト(音声ファイル)

Amazon Connect のデフォルトとして用意されているプロンプト(音声ファイル)は以下になります。
別途、用意した音声ファイルをアップロードして使用することが可能です。

Beep.wav
Music_Pop_ThisAndThatIsLife_Inst.wav
Music_Pop_ThrowYourselfInFrontOfIt_Inst.wav
Music_Rock_EverywhereTheSunShines_Inst.wav
Music_Jazz_MyTimetoFly_Inst.wav
上記音声ファイルの所有者はAmazonです
Amazon Connect で設定されている内容を確認する目的で上記ファイルを設置しています
別の目的でファイルの利用をすることはお断りさせていただきます

まとめ

問い合わせフローの中で明示的に設定をしなければ、デフォルトの各種フローが適用されます。
デフォルトの各種フローを利用する場合は、必要に応じて設定内容を変更してから利用しましょう。
独自の各種Typeのフローを作成し、設定することも可能です。
メインの問い合わせフローも大切ですが、各種Typeのフローにも心配りをした設定を忘れないようにしましょう。


やっぱりWorkSpacesのコンピュータ名は変えてはいけなかった話

$
0
0

こんにちは、技術4課の城です。
2019年、早くも1月が終わろうとしています、早いです。
諸事情あり、掲題の件、改めて確認してみました。

結果から

タイトル通り、やはりWorkSpacesのコンピュータ名は変えてはいけません。
クライアントからは即接続不能となり、ある程度時間が立つとステータスがUnhealthyに変わります。

なぜ試してみたか

とあるお客様から、「コンピュータ名変更できないですか?」と相談を受け、調べていたところ、下記フォーラムの記載を見つけました。
Setting ComputerName/Hostname of WorkSpace for AD

Active Directory(以降、AD)サーバーからRename-Computerを実行すれば、もしかしていけるのか?と淡い期待を持ったわけです。
しつこいようですが、ダメだったわけで。

やったこと

ADサーバー、AD Connector、WorkSpacesという構成を作成。
ADサーバーからRename-ComputerでWorkSpacesのコンピュータ名を変更してみました。

実行前

ADサーバーに登録されたWorkSpaces(コンピュータオブジェクト)を確認すると、 IP-C6137550という名前がついています。

コンピュータ名変更

ADサーバーにて下記コマンドを実行します。

Rename-Computer -ComputerName "IP-C6137550.testdc.local" -NewName "TEST-WORKSPACES" -DomainCredential testdc.local\Administrator -Force -PassThru -Restart

【結果】

HasSucceeded OldComputerName           NewComputerName
------------ ---------------           ---------------
True         IP-C6137550.testdc.local  TEST-WORKSPACES

接続を試してみます

が、接続できません。

RDPは可能でした。

復旧策

コンピュータ名を戻し、再起動したところ、接続可能になりました。

Rename-Computer -ComputerName "TEST-WORKSPACES.testdc.local" -NewName "IP-C6137550" -DomainCredential testdc.local\Administrator -Force -PassThru -Restart

まとめ

ドキュメントを色々と見てみたところ、Amazon WorkSpaces に関するトラブルシューティングに、Unhealthyとなる原因の一つとして記載がありました。

WorkSpace のコンピュータ名が変更された場合。これにより、Amazon WorkSpaces と WorkSpace の間に確立されるべき安全な交信が妨げられます。

今回は仕様上出来ない事の記事となりましたが、どなたかの助けになれば幸いです。

[MSP/AWS運用代行] 簡単なデータ集計と可視化を使って運用の改善を考える

$
0
0

こんにちは、マネージドサービス課の橋本です。最近はAthena、QuickSight、Jupyterあたりが仲良しなプロダクトです。

今日のトピックは弊社が展開している「AWS運用代行」というサービスの内側の話です。中の人の一員として、サービス改善のために実施している取り組みの一つを簡単にご紹介したいと思います。

背景

弊社の「AWS運用代行」は、監視基盤とチケットシステム、24/365の有人対応体制などを中核とする運用サービスです(資料はこちらよりダウンロード可)。ざっくり説明すると、障害発生時の対応フロー(実施する作業内容や関係者への連絡の方法など)をお客様と弊社の間で事前に取り決めておき、本稼働後はこれに準じた障害対応を実施するというものです。

サービス基盤の開発を手がける者や、現場で受け入れ調整を行う者、業務フローの改善を担う者など、様々な関係者によって運営されている本サービスですが、その中で私が関与しているのが所謂データ分析のセクションになります。

現時点の状況は、分析に必要なデータを集める仕組みが軌道に乗りそう、ぐらいの感じです。機械学習のような高度なタスクはほぼ実施していません。ゆくゆくはそちらにも展開を広げていくつもりです。

今、何をしているのか

集計/可視化/考察/改善アクションの提案と(必要に応じて)実行、といったところです。内部のオペレーションを効率化するネタが今の検討の中心です。

R&D的なタスクもいくつか手を出しています。ネタ的には自然言語処理や協調フィルタリングあたりが絡みます。

現在は一段落しつつありますが、以前は集計の仕組みを立ち上げるために開発や運用現場の方と諸々調整したりもしていました。

直近の活動としては、QuickSightを使った障害チケットの集計・可視化を行いました。これについて、以下でご紹介します。

QuickSightでアラート発生数の可視化

分析するにもまずは集計と可視化からということで。チケットシステムのチケット数を集計してみました。

システム概要

概要構成図を以下に示します。基本的には、チケットシステムで発生した何らかの状態変化をLambda Functionにトリガーし、更新後のチケット状態をS3にどんどんPUTしていくことで集計の元データを蓄積しています。分析担当者は、蓄積したデータをAthenaやQuickSightを用いて眺めていくことになります。

可視化してみる

実際の画面サンプルを以下に示します。

アラートの発生数を顧客ごと/アラート種別ごと/時間帯ごとで把握する狙いのグラフを作成しています。Controlsで期間条件を付けています。チケット単位の対応工数なども取得可能です。

集計タスクの内容によってはAthenaでクエリすることもあります。必要に応じてPythonやExcelを用いてレポーティングすることもあります。

考察する

可視化を行う一番の目的は、改善業務のリソース配分を効果的に決めるための判断情報を提供することです。障害実績の傾向を把握することで、時間帯に応じてアサインしておくべきリソース量の当たりを付けたり、頻発傾向にあるアラートの対応工数省力化を検討したり…といったようなことに利用します。数字のレポートと考察、可能なら改善案の叩きを添えて定例などで報告します。

以前に手がけた集計タスクの事例を、1つご紹介します。以下。

CPU/メモリなどのリソース系監視項目は、経時によって自然回復するケースがそれなりにありました。そこで「アラート発生から回復するまでの時間」を顧客横断でサンプルし、復旧時間の分布を眺めてみました。この分布を累積の形で表現すると「このアラートがN分で自然回復する割合はXX%」といったことが視覚的に表現できます。データサンプルが集まれば、この分布をより細かいグループ(顧客ごと、もしくは監視対象ごと)で見ることも可能でしょう。

…と、このような共有を行いました。字面だけでも寂しいですので、実際に可視化した様子を下の図で示します。これは、あるリソース系アラートについて、障害発生〜復旧までに要した時間(つまり復旧時間)を累積分布で図示したものです。指数的な積み上がりをしている様子が見て取れるかと思います。

上記の共有を行った後、チーム内で次のような議論がありました。

リソース系アラートの対応フローは、「発生時点では通知のみ実施して一時的に静観する。アラート状態が長時間継続された場合にはチケットの緊急度を上げてエスカレーション対応を行う」としているケースがそれなりに多く存在している。
「一時的な静観」のしきい値を、先の集計結果を基にいい感じに調節できれば、担当者が目にするアラート通知のS/N比が改善するのではなかろうか?

基本的にアラート通知の設定は、取りこぼしたときの罪が深い分「通知が過剰気味になろうとも、漏れなく通知する」方針に寄りがちです。クリティカルレベルの障害通知のS/N比が改善することで、運用担当者の負担を減らすメリットに繋がるはずだ、と。

現在のAWS運用代行サービスですが、リソース系アラートの「一時的な静観時間」のデフォルト値はこの集計結果を基に決定しています。数字の根拠は正直厳密でない部分もあると思いますが、当てずっぽうに静観時間を決めるよりは実績に基づく分だけ信頼できると思われます。

雑感

今の取り組みについて、考えていることなどを雑に述べます。

今後目指していきたい方向性

ここまで述べてきたことは、基本的に「今既に存在するもの」を何かしら改善していく観点です。私としてはもっと色々な方面に活用していきたい思いが強く、ぼんやりと次のような展開を考えています。

(1) 「攻めた」改善をやる

統計や機械学習のエッセンスを含んだ何かしらができればと思っています。たとえば、要エスカレーションの事象(≒チケット)の発生に対して、近しい過去対応実績をレコメンドして対応速度の向上に繋げたり…とか。

正直まだ妄想の域を出ませんが、(私自身の趣味と実益を兼ねて)ここは進めていきたいです。

(2) マネジメント層への交渉材料にする

「こういう取り組みしたいからこのぐらい金(or人)出して」などの交渉を有利に進められるようにしたいなぁ…という趣旨です。適切な投資を引き出すためには、定量的な議論の材料を示すことは必要であろうと考えています。

改善は泥臭い

考察して「こうした方がいいよ」と言ってみても、アクションを伴なければビジネスの成功にはつながらないわけで…。実装に落とすために基盤システムの仕様を把握する必要があったり、現状の業務ルールとの兼ね合い、既存環境への適用可否や適用方法、告知の手段などなど、考えるべきことはそれなりにあります。

数字を扱うことよりむしろ、その結果得られた示唆をビジネスの成果につなげることの方がよほどハードなタスクだなと最近は感じます。

まとめ

まずはデータが取れる & 見える環境づくりから、ということで取り組みを始めてみました。執筆時点(2019年1月)ではデータ収集と可視化が形になってきた、というところです。機械学習のような意識高い系ソリューションはまだまだこれからですが、そうした技術が適用できる問題領域も今後出てくると思いますので、活用していきたいですね。随時改善を回していきますので、弊社のAWS運用代行を引き続きよろしくお願いいたします。

AWS WAF セキュリティオートメーションソリューション2.2.0

$
0
0

AWS WAF セキュリティオートメーションソリューションという簡単にAWS WAFを導入できるCloudFormationテンプレートがありますが、気がついたらバージョンアップしてました。

調べてみると、確かに日本語でも情報でていますね。
AWS WAF セキュリティオートメーションソリューションにモニタリングダッシュボードが導入されました

2019年1月29日現在で、バージョン2.2.0の環境が作成されます。
GitHubを見ると、やはり2018年12月末に2.2.0になったことが確認できます。
https://github.com/awslabs/aws-waf-security-automations

以下で従来バージョンとの違いをみていきます。

モニタリングダッシュボードの追加

日本語情報にある通りなんですが、CloudWatchにダッシュボードが追加されました。
BlockRequestsとAllowedRequestsが確認できます。
(上記画像は実際にまだアクセスが無いのでカウントされていません。)

ALB用とCloudFront用のテンプレートが1つに統合

以前はCloudFront用とALB用でCloudFormationテンプレートが分かれていたのですが、1つになりました。
これを使えばOKです。
https://s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations.template

とはいえ、実際に試してみると、内部的にはCloudFormationのネスト機能で、2つのテンプレートを1つにまとめているようです。

AlbStackとCloudFrontStackがあり、別のところからファイルを取ってくる仕様になってました。

Resources:
  AlbStack:
    Type: 'AWS::CloudFormation::Stack'
    Condition: AlbEndpoint
    Properties:
      TemplateURL: !Join
        - '/'
        - - 'https://s3.amazonaws.com'
          - !Join ["-", [!FindInMap ["SourceCode", "General", "S3Bucket"], !Ref 'AWS::Region']]
          - !FindInMap ["SourceCode", "General", "KeyPrefix"]
          - 'aws-waf-security-automations-alb.template'
      Parameters:
        SqlInjectionProtectionParam: !Ref SqlInjectionProtectionParam
        CrossSiteScriptingProtectionParam: !Ref CrossSiteScriptingProtectionParam
        ActivateHttpFloodProtectionParam: !Ref ActivateHttpFloodProtectionParam
        ActivateScannersProbesProtectionParam: !Ref ActivateScannersProbesProtectionParam
        ActivateReputationListsProtectionParam: !Ref ActivateReputationListsProtectionParam
        ActivateBadBotProtectionParam: !Ref ActivateBadBotProtectionParam
        AccessLogBucket: !Ref AccessLogBucket
        WafApiType: 'waf-regional'
        WafArnPrefix: !Join ['', ['arn:aws:waf-regional:', !Ref 'AWS::Region',':']]
        ParentStackName: !Ref 'AWS::StackName'

  CloudFrontStack:
    Type: 'AWS::CloudFormation::Stack'
    Condition: CloudFrontEndpoint
    Properties:
      TemplateURL: !Join
        - '/'
        - - 'https://s3.amazonaws.com'
          - !Join ["-", [!FindInMap ["SourceCode", "General", "S3Bucket"], !Ref 'AWS::Region']]
          - !FindInMap ["SourceCode", "General", "KeyPrefix"]
          - 'aws-waf-security-automations-cloudfront.template'
      Parameters:
        SqlInjectionProtectionParam: !Ref SqlInjectionProtectionParam
        CrossSiteScriptingProtectionParam: !Ref CrossSiteScriptingProtectionParam
        ActivateHttpFloodProtectionParam: !Ref ActivateHttpFloodProtectionParam
        ActivateScannersProbesProtectionParam: !Ref ActivateScannersProbesProtectionParam
        ActivateReputationListsProtectionParam: !Ref ActivateReputationListsProtectionParam
        ActivateBadBotProtectionParam: !Ref ActivateBadBotProtectionParam
        AccessLogBucket: !Ref AccessLogBucket
        WafApiType: 'waf'
        WafArnPrefix: 'arn:aws:waf::'
        ParentStackName: !Ref 'AWS::StackName'

 

設定画面

Endpoint Type だけ追加ですね。
CloudFrontかALBが選択できます。
(ALBを選択すればAPI Gatewayでも動かせると思いますが、まだ試していないです。)

WebACLの中身

v2.1 v2.2.0
Whitelist Rule Whitelist Rule
Blacklist Rule Blacklist Rule
Http Flood Rule Http Flood Rule
Scans Probes Rule Scanners & Probes Rule
WAF IP Reputation Lists Rule #1 WAF IP Reputation Lists Rule
WAF IP Reputation Lists Rule #2  
Bad Bot Rule Bad Bot Rule
SQL Injection Rule SQL Injection Rule
XSS Rule XSS Rule

全体的にリソース名にランダム値がつくようになってしまったのですが、それを除外したルール名を上記に記載しました。
v2.1では9つあったルールが、v2.2.0では8つになりました。
一つのWebACLには10のルールしかつけられないという制限があるので、ユーザー独自のルールやマネージメントルールを追加しやすいように少し余裕を持たせたのかもしれません。

その他は基本的には変わっていませんでした。
(もしかしたらLambda Functionの中身などは変わっているかもしれません。)

まとめ

セキュリティオートメーション のテンプレートは、更新されないと思っていたのですが、時々更新されるようです。

[Amazon SageMaker] AWS Marketplaceのモデルを使ってみた

$
0
0

こんにちは、PS課の峯です。

Amazon Sagemakerではユーザーがモデルをトレーニングしてデプロイするだけでなく、AWS Marketplaceでトレーニング済みモデルを購入しデプロイすることもできます。

SageMakerの左下からAWS Marketplaceへ。

すでにAmazon Sagemakerにチェックが入っています。

今回はこちらの無料のトレーニング済みモデルを使用します。
歌詞を生成するモデルのようです。
「Continue to Subscribe」をクリックして進みます。

説明を読んで「Accept Offer」をクリックします。このモデルはml.c5.xlargeしか使えないようです。他のモデルでも利用できるインスタンスタイプが限られているものがあります。モデル自体は無料でもエンドポイントを作成するとそのインスタンスタイプ分の料金はかかるので注意しましょう。

バーションやらリージョンを選択し、「View in SageMakher」をクリック。

するとSageMakerのコンソールの推論 > モデルパッケージ > AWS Marketplaceのサブスクリプションに追加されていればOKです。
あとはモデルパッケージを選択し、アクションからモデル/エンドポイントを作成すれば予測が行えます。

ちなみに

ここではエンドポイント作成手順は省略しますが、「lyric-generater」という名でエンドポイント作成後、以下のように雑な感じで予測を行ってみました

import ast
import sagemaker


endpoint_name = "lyric-generater"
payload = bytes('''{"instances":[{"artist":"taylor swift","seed":"sagemaker"}]}''',encoding="utf-8")

predicter = sagemaker.predictor.RealTimePredictor(endpoint_name)

result_str = predicter.predict(payload).decode()
result = ast.literal_eval(result_str)
lyric = result['predictions'][0]['lyrics']
print(lyric)

ちなみに歌詞はこんな感じ…(成形してあります。)

Sagemaker
she walk around
she wanna be said
she can't have to say
her life is a city 
and she want the world in the morning
its just she was a fool
she said she was crazy
she'll say how many times
she will never do the shadow
she said she says
but she was proud
nand she was shirting
come on and be something she could
she like it but she loves me
i got some shake and she don't
but she don't know about me
I can do it for you
she wants to be mad
can't you see that she can survive
i don't wanna know
i don't know if the same
{以下略}

【サバワコネクト2018】Amazon Connectサーバーワークス社内活用事例まとめ

$
0
0
自社で使ってみて“すごさ”を実感したことをお客様に提供したい。
わたしたちサーバーワークスでは新しい技術を社内でドッグフーディングする風習があります。
Amazon Connect も例外ではありません。
 
2018年12月に Amazon Connect は東京リージョンに対応しました。
したがって2018年における Amazon Connect の活用はほぼシドニーリージョンでの利用となりました。
 
利用できる電話番号は DID番号(050) トールフリー番号(0800) の2種類で、電話番号の持ち込みはまだできません。
したがって、代表電話番号 03-5579-8029 等既存の電話番号を Amazon Connect に置き換えるということは実現できていません。
 
それでも部分的に Amazon Connect を活用しました。
2018年 サーバーワークスにおいて Amazon Connect をどのように利用してきたかをご紹介します。
 

サーバーワークス 2018年 Amazon Connect 活用事例

活用1:インサイドセールスのアウトコールダイヤル

サーバーワークスの営業部隊にはインサイドセールスチームがいます。
インサイドセールスチームはリードをフィールドセールスにつなぐのはもちろん、案件のクロージングまで担当することもあります。
メールや電話のやりとりは活動をする上で非常に大切な役割を担います。
Salesforceの商談に活動を記録しますが、電話は話した内容をそのまま残すわけではありません。
どんなやりとりをしたか、あとから確認したくても今まではできませんでした。
Amazon  Connect では通話録音ができます。録音した音声をあとから聞くことが可能です。
OJT中のメンバーの電話応対内容をあとからチェック!といった活用もしています。
 

活用2:海外営業メンバーの活動用電話

サーバーワークスでは、海外で活動している営業メンバーがいます。
期間限定ですが海外生活をしながら、日本のお客様に営業活動ができちゃうんです。
クラウドの会社らしい働き方ですね。
 
このチャレンジで課題となった件の1つが電話です。
営業なので電話は必要です。
利用する電話を検討し採用されたのが Amazon Connect です。
お客様への連絡(受発信)に Amazon Connect (DID 050番号) を利用しています。
Amazon Connect を利用することで電話機やキャリアとの契約は不要になりました。
 

活用3:データ通信専用SIMでも個人電話

サーバーワークスでは業務で必要な場合に個人用の電話番号を発行しています。
BYOLしたスマートフォンで付与された050番号が利用できます。
しかし利用できるのは、音声通話に対応しているSIMカードを利用している場合に限ります。
データ通信専用のSIMカードを使っているエンジニアが電話番号を必要としたときに対応できずに困りました。
しかし、こんなときも Amazon Connect 。
ネットワークにつながるPCだけで電話応対が可能です。
 

活用4:Amazon ConnectのキャンペーンをAmazon Connectで実施しました

東京リージョン上陸に合わせて Amazon Connect キャンペーンダイヤルを設置しました。
 
1月末をもって無事キャンペーンは終了しました。
約2ヶ月の期間、無人でキャンペーン対応ができました。
件数はそれほど多くありませんが、この件数のお問い合わせに人手で対応した場合と比べるとかなりのコスト削減になります。
このキャンペーンでかかったAWS利用料金は$1.02でした。
利用料金から逆算すると利用件数(時間)が計算できますが
件数が少ないながらも、100円ちょっとで電話のキャンペーンができるって Amazon Connect なしでは考えられないですよね。
 

PoCも実施しました

すでに記事を公開していますが、代表電話をConnectに置き換えるPoCも実施しています。
 
 

まとめ

2018年にサーバーワークス社内で Amazon Connect を活用した事例は以上です。
サーバーワークスでは得意のドッグフーディングで体験したした成功例、失敗例をみなさまの案件に還元しています。
2019年のチャレンジもご期待ください。
Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>