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

EBSにタグをつけるスクリプトを作った

$
0
0

アソシエイト3冠の渡辺です。
EBSボリュームにタグをつけるスクリプトを作成しました。

仕様

  • コマンドライン引数にEC2のインスタンスIDを取る(複数可)
  • EC2インスタンスのタグをそのままアタッチされているEBSボリュームにつける
  • EBSボリュームが複数ある時は全てのEBSボリュームにつける

作成した理由

大量のEC2インスタンスに大量のタグをつける案件に遭遇してしまいました。。。
しかも、EBSにもつける必要があります。

サーバーワークスの構築はCloudFormationが主流です。
しかし、残念ながらCloudFormationはEBSのタグには対応していないようです。

自動的に作成されたタグを含むすべてのスタックレベルのタグは、AWS CloudFormation がサポートするリソースに反映されます。現在のところ、タグはブロックデバイスマッピングから作成された Amazon EBS ボリュームには反映されません。
AWS CloudFormation Resource Tags タイプ

ちょっと聞いた感じ、クリックだけで乗り切るには危険な量でした。

スクリプト

import boto3
import sys

def main(argv):
    ec2 = boto3.resource('ec2')
    for instanceid in argv:
         volumes = []
         instance = ec2.Instance(instanceid)
         tags = dict([(tag['Key'], tag['Value']) for tag in instance.tags])

         for device in instance.block_device_mappings:
             volumeid = device['Ebs']['VolumeId']
             volumes.append(ec2.Volume(volumeid))

         for volume in volumes:
             for key, value in tags.items():
                  volume.create_tags(
                      Tags=[
                          {
                              'Key': key,
                              'Value': value
                          },
                      ]
                  )

if __name__ == "__main__":
    main(sys.argv[1:])

 

使い方

EC2のインスタンスIDを引数にとってスパッと実行してください。

python create_tags_ebs.py i-xxxxxxxxxxxxxxxxx i-yyyyyyyyyyyyyyyyyyy i-zzzzzzzzzzzzzzzzzz

 


Amazon Connect の限界を知りたい

$
0
0

先日コンタクトセンター界の黒船、Amazon Connect が数ヶ月以内に東京リージョンで利用可能になることが発表されました。
ウェルカム、トーキョー!
上陸が待ち遠しいですね。

Amazon Connect もAWSのサービスの1つ。
AWSを利用する上で定期的にぶちあたる壁がサービス制限と上限緩和。
今日は Amazon Connect のサービス制限(Service Limit)についてまとめます。

Amazon Connect サービス制限のドキュメント

本日(2018-10-24)の時点では英語ドキュメントのみ提供されています。
What Is Amazon Connect? というページの Service Limits にサービス上限がまとまっています。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/what-is-amazon-connect.html

Amazon Connect サービス制限

※2018-10-24現在の情報です

制限項目について

以下項目でDefault Limitが設定されています。
対応する日本語の項目と制限単位を確認しました。

Item 制限項目項目/制限単位 Default limit
Amazon Connect instances per account Amazon Connect インスタンス / AWSアカウント 5
Users per instance ユーザー数/インスタンス 500
Phone numbers per instance 電話番号の数/インスタンス 10
Queues per instance キューの数/インスタンス 50
Queues per routing profile キューの数/ルーティングプロファイル 50
Routing profiles per instance ルーティングプロファイル/インスタンス 100
Hours of operation per instance オペレーション時間(キューが利用可能な時間の定義)/インスタンス 100
Quick connects per instance クイック接続の数/インスタンス 100
Prompts per instance 音声プロンプトの数/インスタンス 500
Agent status per instance エージェントステータスの数/インスタンス 50
Security profiles per instance セキュリティプロファイルの数/インスタンス 100
Contact flows per instance コンタクトフローの数/インスタンス 100
Groups per level エージェント階層 Agent hierarchyの各レベルごとに作成可能なグループの数 50
Reports per instance 保存したレポートの数/インスタンス
Real-time metrics/Historical metrics/Login/Logout reportの合計をカウント
500
Scheduled reports per instance スケジュール設定されたレポートの数/インスタンス
Historical metrics/Login/Logout reportの合計をカウント
50
Concurrent active calls per instance アクティブな接続/インスタンス 100

上限緩和について

すべての項目で上限緩和申請可能であることを確認しています。
Amazon Connect instances per account のみ上限緩和のケース作成の該当項目がありませんが、申請は可能とのことです。

ナンバーポータビリティーについて

現在USのみ対応しています
東京も対応してくれないかしら、期待しています!

発信コール用のホワイトリスト

日本のみの利用の場合は気にしないでよさそうです
海外でも利用する場合は注意

サポートの専用カテゴリからホワイトリストの追加申請が可能です
発信可能な国
Australia
Canada
China
Germany
Hong Kong
Israel
Japan
Mexico
Singapore
Sweden
United States
United Kingdom ※477の英国電話番号は含まれていないので注意

まとめ

上限緩和申請できない項目もあるのではないかとドキドキしたのですが、サポートに問い合わせたところすべての項目で対応可能と回答をいただきました。
安心して大規模運用を想定した利用ができますね。

サーバーワークスではConnectの導入支援も積極的に行っています。
東京上陸前のご相談もお気軽にどうぞ。

【EC2】インスタンス間でSQL Server AlwaysOnを構成する際のセキュリティグループ設定

$
0
0

はじめまして。技術4課の伊藤Kです。
つい最近サーバーワークスにジョインし、初投稿となります。
このブログにはサーバーワークスの誇るZabbixプロフェッショナル伊藤(qryuu)さんが数多く投稿しておりますので、
別の伊藤と分かるように伊藤Kと名乗ることにします。

今回は小ネタ。EC2の2インスタンス間でSQL Server AlwaysOn 可用性グループを構成する際のセキュリティグループ設定について。まとまった情報がなかなか見つからない部分なのでまとめておきます。

前提条件

まずは前提条件です。

・SQL Serverがインストールされたインスタンス2台ともActive Directoryドメイン参加を完了し、ドメイン認証に必要なセキュリティグループは構成済みとします。

・マルチサブネットでのAlwaysOn 可用性グループ構成です。構成図は以下となります。

・Windows Server 、SQL Serverのバージョンエディションは下表の通りです。

OS Windows Server 2012 R2 Standard Edition
SQL Server SQL Server 2014 Enterprise Edition SP1

セキュリティグループ一覧

最終形は下表となります。Outboundはここではすべて許可としております。
セキュリティグループ「securityGroup1」をインスタンス2台ともに関連付けます。

Inbound

プロトコル ポート範囲 ソース
TCP 135 securityGroup1
TCP 137 securityGroup1
TCP 445 securityGroup1
TCP 1433 securityGroup1
TCP 1434 securityGroup1
TCP 3343 securityGroup1
TCP 5022 securityGroup1
TCP 5985 securityGroup1
TCP 49152-65535 securityGroup1
UDP 137 securityGroup1
UDP 1434 securityGroup1
UDP 3343 securityGroup1
UDP 49152-65535 securityGroup1
ICMP すべて securityGroup1

参考にした情報

SQL Server AlwaysOn 可用性グループはオンプレミス環境では構築経験があるのですが、オンプレでは基本的に全通しですからね・・・
いざ、「必要な通信は」と言われると戸惑うものです。
AWSでもMicrosoftでもまとまった情報がなく、調査に時間がかかりました。

最終的にはAWSクイックスタートのSQL Serverの項目で公開されている「CloudFormationのテンプレート」を読む、という作戦(同じ課の先輩に教わりました。さすが!)でほぼ完成形となりました。
ステップ 2. クイックスタートを起動する – AWS での SQL Server と WSFC

参考として上記が見つかる前に元にしていた情報は、
「AlwaysOn構成に必要なポート」ということでこのサイト。
Azure VM での AlwaysOn 可用性グループの手動構成

あとはWSFCの構成に必要なポートということで、このサイトの「クラスター サービス」部分。
Windows のサービス概要およびネットワーク ポート要件

エラー発生情報

「RPCによってランダムに割り当てられた非特権TCPポート」(TCP 49152~65535)を追加していなかったケースで、
クラスター構成時に対抗インスタンスを追加する際にタイムアウトが起きました。
 ↓ここで対抗側のコンピューター名を入力して「追加」ボタンをクリックするとタイムアウトとなる。

最後に

 この記事でもそうですが、個人的には記事に「エラー発生情報、イベントエラーのメッセージ」を可能な限り記載する方針です。
 理由としては、字数をかせぐためこういった技術系ブログは、エラーで困った人が現象のキーワードやエラーイベントの番号、メッセージから何度も検索して「解決する情報が載っていないか」と期待してたどりつくことが多いと思います。その際に検索にひっかかやすいようにするためです。
 自分もそうやって検索して、インターネットに自分の知見を公開してくれる先達たちに何度も助けられています。こうして知ったことを公開することで少しでも恩返しになれば、そう願っています。

 今後ともサーバーワークスともどもよろしくお願いいたします。

【EC2】英語版Windows ServerのAMIから起動、日本語化したらリモート管理でエラー

$
0
0

こんにちは。技術4課の伊藤Kです。
先日はハロウィンでした。日本の各所でイベントが行われていたようですが、
ハロウィンはいつごろから日本に定着したんでしょうか。
節分の「恵方巻」とともに謎に思っている関東人です。

ちなみにサーバーワークスでもハロウィンでささやかに盛り上がりました。
仕事の合間に無料でできる、仮装パーティーの始め方(1日限定!)

さて今回は小ネタです。

EC2インスタンスで英語版Windows Server 2012 R2のAMIから起動し、その後言語設定を日本語化しました。
最初から日本語版を使えればよかったのですが、特定のバージョン/エディションのSQL Serverを使用するためには英語版しか選択肢がなかったのです。
日本語化した後、OSの「リモート管理」機能が使えなくなりました。

言語設定の日本語化手順

OSはWindows Server 2012 R2 英語版です。以下のブログ過去記事の手順を実行しました。
サーバーワークスエンジニアブログ – Windows Server 2012 R2英語版の日本語表示

エラーが発生していた

しばらくは気づかずに使っていたのですが、あるときふとサーバーマネージャーを見ると、リモート管理の状態が「不明」になっています。

「不明」のリンクをクリックすると下図の画面が表示されました。

内部エラー:リモート処理の状態を読み取ることができませんでした: 指定されたファイルが見つかりません。

リモート管理を有効にする必要があったので「他のコンピューターからのこのサーバーのリモート管理を有効にする」にチェックを入れて[OK]ボタンをクリックしましたが、エラー表示(スクリーンショット取りそこないました)となり、有効にできません。

対応方法

コマンドプロンプトを「管理者として実行」で起動して、以下のコマンドを実行します。

netsh advfirewall firewall add rule name="Windows リモート管理 (HTTP 受信)" dir=in action=allow service=any enable=yes profile=any localport=5985 protocol=tcp

特にOS再起動も必要なく「有効」に戻りました。

原因は、言語設定を変更することで、OSがリモート管理の使用に必要な Windowsファイアウォールのルールを認識できなくなったためのようです。上記コマンドでそのルールを追加しています。
本事象はWindows ファイアウォールそのものを「無効」にしていても発生します。
(コマンド実行前にWindowsファイアウォールの管理コンソールを開くと同名のルールが一見存在するように見えるのですが、何かが違うのか、内部的にそれを認識できていない状態なのか、コマンドの実行が必要となります。)

おまけ

現象を元に検索すると、まず見つかるのが「winrm quickconfig」コマンドで解決する、という記事。
しかし、今回の現象では「winrm quickconfig」コマンドを実行すると以下のエラーメッセージが表示されて解決に至りませんでした。

Message = ファイアウォールの状態を確認できません。
エラー番号:  -2147024894 0x80070002
指定されたファイルが見つかりません

おわりに

記事を書くために再現実験をしましたが、事象は必ず発生するわけではなく何らかがトリガーとなって発生するようです。(トリガーは特定できず)
本事象で困っている方の助けになれば幸いです。

AWS認定 Security -Speciality 合格レポート

$
0
0

こんにちは、技術4課の城です。
先日AWS認定 Advanced Networking -Specialityについてのレポートを書きましたが、セキュリティって結構ネットワークと重なるところが多い気がします。
というわけで、AWS認定 Security -Specialityを受験してきましたのでレポートをしたいと思います。

AWS認定 Security -Specialityとは

AWSのセキュリティについての専門知識試験となります。
下記、公式サイトより抜粋です。

AWS 認定セキュリティ専門知識は、セキュリティロールを遂行する人を対象としており、AWS プラットフォームのセキュリティ保護についての理解度を評価するものです。

詳細内容は公式サイトをご覧ください。

受験料:32,400円(税込み)
時間:170分

受験時のスペック

簡単に受験時の自身のスペックをセキュリティverにてお送りします。
セキュリティ関連の業務経験ですが、専門的には特にありません。

AWS歴 業務利用はサーバーワークスに入社してからの11カ月
認定 アソシエイト3種、プロフェッショナル2種、Advanced Netwoking取得済み
その他セキュリティ系の資格 情報処理安全確保支援士
エンジニア歴 もうすぐ4年になります。

事前にやったこと

下記、実施しました。

試験ガイドを読む

試験のレギュレーションは押さえておきましょう。
特に配点の高い分野で弱点がある場合は重点的に取り組みたいところです。

サンプル問題を解く

不正解の選択肢についても、なぜ不正解なのかを整理しておくことが重要です。

模擬試験

この試験については模擬試験が用意されていますので、受験しました。
自身の弱点をあぶりだします。

オンラインで受験可能で、受験料は4,320円(税込み)でした。

AWSクラウド活用資料集(Blackbelt)

模擬試験の結果、私は特にLogging and Monitoring、Data Protectionが弱かったので、次のBlackbelt資料を熟読しました。

その他、次のサービスについても目を通しました。

KMSのハンズオン

KMSについて概要は知っていたものの、実際に利用したことがなかったので、JAWS-UG CLI専門支部のKMS回をやってみました。
CLIでサービスを使うのは、どんなAPIがあって、どのような引数で実行しないといけないのかなどが分かりやすく、大変お勧めです。

※JAWS-UG CLI専門支部ではおよそ2週間おきにAWSの色々なサービスについてAWS CLIを用いてハンズオンを行っているコミュニティです。
https://jawsug-cli.doorkeeper.jp

LinuxAcademyの利用

講義のビデオを見たり、確認テストを受けたりしました。
確認テストを複数回実施し、解説を読み込む、加えてBlackbletの該当部分を見返すなどしていました。

結果

スコア:848/1000にて合格しました!!

合格基準は試験ガイドに下記記載があります。

試験結果は 100~1000 点の範囲のスコアでレポートされます。最低合格スコアは 750 点です。

余談ですが、試験終了画面での合否表示はきちんと確認しておきましょう。
今まで取得した認定では終了後すぐに送付されるメール内に合否やスコアレポートの記載があったのですが、今回は完了としか表記がなく、認定アカウントで確認できるまで、だいぶソワソワしてました。。。
参考ですが、今回は試験終了後、3営業日後に閲覧できるようになっていました。
※公式的には「受験日から5営業日以内に試験結果を閲覧することが出来る」とのことです。

まとめ

普段あまり触らないようなサービスについても、知識として整理できるのが、資格取得のメリットの一つかと思います。
是非みなさまもチャレンジしてみてはいかがでしょうか?

どなたかの助けになれば幸いです。

CloudEndureの画面をペタペタ貼り付けていくぞ

$
0
0

渡辺です。
CloudEndureは、ライセンス費用が移行1台単位でかかり、テストライセンスもありません。
ライセンス購入前にテストができないため、事前に挙動が理解しにくいところがあります。
本記事ではCloudEndure移行作業時のスクリーンショットを貼り付けていきます。
CloudEndureがどのように動くか、理解の助けになれば幸いです。

目次

1.エージェントのインストール確認する方法

CloudEndureではソースサーバ(移行元のサーバ)へのエージェントインストールが必要です。
往々にしてソースサーバにはインターネット側からログインできないため、顧客がインストール作業を行います。
その後、弊社側でインストール成功したか確認することになります。
画面のようにAudit Logで確認可能です。

2.レプリケーション進捗を確認する方法

レプリケーション開始後、どれくらいの時間で完了するのか気になります。
画面のようにMachinesでレプリケーション進捗が確認可能です。
上記の例だと進捗19.52%、あと2日程度かかる見込みということですね。

3.レプリケーションサーバのAWS上の見え方

エージェントのインストールが完了し、レプリケーションを開始すると、AWS上で自動的にレプリケーションサーバが作成されます。
このレプリケーションサーバがソースサーバから送信されるデータを受け取ります。
画像のように「CloudEndure Replication Server con 16」という名前でt2.smallが起動します。

4.EBSボリュームのAWS上の見え方

初期レプリケーションが完了すると、EBSボリュームが作成されていることに気づきます。
AWS上でレプリカがLaunchされる時、このEBSボリュームにスナップショットを反映させ、起動しているのだと思われます。
なお、上記で2つあるのは、ソースサーバがCドライブとDドライブを持つからです。

5.セキュリティグループのAWS上の見え方

レプリケーションサーバが起動する時に「CloudEndure Replicator Security Group」というセキュリティグループが自動作成されます。
アウトバウンドの制限もあるので、レプリケーションサーバがプロキシサーバを利用し、上記以外のポート番号利用の場合は追加設定が必要となります。

6.スナップショットのAWS上の見え方

初期レプリケーションが終わった後も、ソースサーバは差分データをレプリケーションサーバに送り続けます。
差分データがスナップショットとして作成され続けます。

7.コンバータサーバのAWS上の見え方

レプリケーション完了し、レプリカサーバをLaunchする時の処理用として「CloudEndure Machine Converter con16」というEC2インスタンスが起動します。起動時間は数分程度なので存在に気づかないかもしれません。

8.Launch失敗時のエラーメッセージ

failedと表示されます。
原因はイマイチわからないのですが、設定を見直したり、CloudTrailを見ると解決する時があります。
サブネット指定を間違えていたり、AWSのリソース上限が原因だった例はあります。

9.日本語版Windowsの移行でも、AMIはEnglish

ソースサーバが日本語版Windowsだったとしても、AMIとしてはEnglishになります。
実際は日本語Windowsとして使えるので、気にする必要は無いと思われます。

10.移行完了後に不要リソースを削除する方法

移行完了後も放っておくと、AWS上にスナップショットが溜まり続けます。
レプリケーションサーバも起動し続けます。
コスト的にも見た目的にもよろしく無いので、削除しましょう。

Remove Machineをすれば、スナップショットが削除されます。
ソースサーバからエージェントもアンインストールされます。
ソースサーバが0になれば、レプリケーションサーバも削除されます。

JenkinsからAssumeRoleを使って別AWSアカウントのCodeBuildプロジェクトを起動する。

$
0
0

こんにちは。今期から技術1課に移動しました、岩本です。

弊社は、割と柔軟に他部署への転属希望が出しやすく、新しく所属した技術1課は、
よくあるインフラではなく、開発やデプロイメントなどを中心に扱う事が多い課です。
ここ最近は、JenkisnとCodeBuildと戯れる日々が続いています。

本題

やりたい事

  • AWSアカウントAにあるJenkinsサーバーから、AWSアカウントBにあるCodeBuildプロジェクトを実行したい。
  • CodeBuildプロジェクトの起動は、(セキュリティ的な観点から)クレデンシャルではなくAssumeRoleを利用したい。

手順

準備

AWS(IAM)の設定

  • AWSアカウントA(Jenkinsが稼働しているAWSアカウント)にて、IAMユーザーを作成し、シークレットキー/アクセスキーを生成します。
    • この際、該当IAMユーザーへの権限の付与は不要です。
  • AWSアカウントB(Codebuildが起動するAWSアカウント)にて、該当のCodebuildプロジェクトの実行権限を持ったRoleを作成し、アカウントAを信頼する様に設定します。
    • JenkinsからCodebuildへソースファイルの送信はS3を経由するため、特定のS3バケットへのアクセス権限も必要です。
    • 記載は以下の通り。
  • trust relationship

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::12345678909:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Jenkinsの設定

  • Jenkin画面より認証情報を開き、認証情報を登録します。
    • 種類:CodebuildCredensials
    • ID:Jenkin内で使用する名前(任意・ここではsample-idと設定)
    • アクセスキー:AWSアカウントAで作成したアクセスキー
    • シークレットキー:AWSアカウントAで作成したシークレットキー
    • 高度な設定/RoleArn:AWSアカウントBで作成したRoleのARN

JenkinsFile

  • Jenkinsfileには以下のように記載します。

node {
  stage('checkout') {
    checkout scm
  }
  stage('build') {
        awsCodeBuild projectName: "sample-project",
        //Codebuildのプロジェクト名を指定
          region: 'ap-northeast-1',
          sourceControlType: 'jenkins',
          credentialsType: 'jenkins',
          credentialsId: 'sample-id',
          //Jenkinsに設定したIDを指定
          buildSpecFile: buildspec.yml,
          artifactLocationOverride: 's3-backet-name',
          artifactNameOverride: '/',
          artifactPathOverride: "/${env.JOB_NAME}/${env.BUILD_ID}/",
          artifactPackagingOverride: 'NONE',
          artifactTypeOverride: 'S3'
  }
}

まとめ

  • 上記の様に設置することで、一部でアクセスキー/シークレットキーの利用はありますが、
    比較的セキュアに認証情報の付与が行えます。ぜひご利用ください。

【SQL Server on EC2】インスタンス間でAlwaysOnを構成する [1. OS準備編]

$
0
0

こんにちは。技術4課の伊藤Kです。
個人的に「感謝しあう雰囲気」が好きですが、
システムとしてそれを実現したUnipos株式会社のサービス「Unipos」に
弊社では「さばチップ」なるネーミングをして導入、好評を博しております。
感謝を伝える仕組みを作る。ピアボーナス「さばチップ」プロジェクトとは?

さてこれまで小ネタが多かったのですが、今回は大きめなテーマ、「2台のEC2インスタンス間でSQL Server AlwaysOnを構成する」で書きます。

SQL Server AlwaysOnには以下の二種類があります。
・AlwaysOn フェールオーバークラスタインスタンス
・AlwaysOn 可用性グループ
今回は、「AlwaysOn 可用性グループ」を構成します。基本的にSQL ServerのEnterprise Editionが必要となりますが(注1)、クラウドの利点を生かすならばほぼこちらの選択肢になるかと思います(注2)。

1エントリにまとめるとさすがに分量が多いため、3回に分けます。

の3本です。

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

作業前の状態、前提

・2台のEC2インスタンスにSQL Serverがインストール済みで、Active Directoryドメイン参加も完了していることを前提とします。

・ドメインコントローラーについては、今回は「AWS Managed Microsoft AD」を構築しました。
 作業はDomain Adminsの権限で、と思いましたが、
 「AWS Managed Microsoft AD」では「AWS Delegated Administrators」が管理者権限グループなので、そのグループに所属させたユーザーアカウントで実施します。
 (このグループが必要最小限の権限かの調査検討はここでは行いません)

・SQL Server の言語はAMIにプリインストールの英語版、ただしSQL Server Management Studioについては日本語版の最新バージョンをダウンロードして各サーバーにインストールしました。(わかりやすさ重視)

・OSの「Windows ファイアウォール」は無効にしております。

・Windows Server 、SQL Serverのバージョンエディションは下表の通りです。

OS Windows Server 2012 R2 Standard Edition
SQL Server SQL Server 2014 Enterprise Edition SP2 (12.0.5000.0)

ちなみに小ネタとして、簡単なSQL Serverのバージョンの確認方法は、
SQL Server Management Studioを起動、対象のコンピューターに接続して、
コンピューター名の右にカッコで表示されるバージョンを確認、それを以下URLの表と照らし合わせることで可能です。
バージョン、エディション、および SQL Server の更新プログラム レベルとそのコンポーネントを確認する方法

・2台のEC2インスタンスの情報、また構築されるクラスターリソースの名前やIPアドレスは下表の通りとします。
「コンピューター名 / リソース名 / リスナー名」は全てADドメインのDNSに登録されるホスト名となります。

内容 コンピューター名 /
リソース名 /
リスナー名
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

VPC、EC2の構成上、WSFC(AlwaysOn)の利点を生かそうとするとマルチサブネットのクラスター構成となります。
そのため、クラスターコアリソース、AlwaysOn リスナーには各サブネットから1つずつIPアドレスが必要です。

EC2インスタンスへのIPアドレス割り当て

では構築に入りますが、まずはEC2のマネジメントコンソールからインスタンスのENIへ設定予定(上記表)のIPアドレスを割り当てます。OSが起動された状態で作業をしても問題ないような気はしますが、念のためにOSをシャットダウンした状態から作業を始めます。

まずは1号機のインスタンスを選択した状態で [ネットワークインターフェイス] のリンクをクリックして、

表示される情報の [インターフェイスID] のリンクをクリック。

インスタンスに結びついたネットワークインターフェイスが選択されますので、その状態で [アクション] メニューから [IPアドレスの管理] を選択。

[IPアドレスの管理] 画面が表示され、コンピューターで使用しているIPアドレスが表示されます。 [新しいIPの割り当て] リンクをクリックします。

上記表の「クラスターコアリソース」のIPアドレス(同サブネットの1つのみ)を入力します。入力途中は右に [無効なIPアドレス] とか表示されますが無視して入力続行。

入力が完了すると [無効なIPアドレス] の表示は消えます。
再度 [新しいIPの割り当て] リンクをクリックして、同様に上記表の「AlwaysOn リスナー」のIPアドレス(同サブネットの1つのみ)を入力します。

入力が完了したら右下の [更新する] ボタンをクリック。

[プライベートIP] の欄が入力状態から表示状態になり、 [更新する] ボタンが押せない状態となったら右上の [×] をクリックして [IPアドレスの管理] 画面を閉じます。

インスタンスの管理画面を表示し、対象のインスタンスの [セカンダリプライベートIP] に設定した値が表示されていることを確認します。

同様に、2号機のインスタンスについても上記の表「クラスターコアリソース」のIPアドレスおよび「AlwaysOn リスナー」のIPアドレスを割り当てます。

割り当てが完了したら、インスタンス2台を起動します。

Windows OSでのIPアドレス設定変更

インスタンスの起動が完了したらインスタンスのWindows OSにリモートデスクトップでログオンし、IPアドレス設定を変更します。

まずは1号機です。OSの [ネットワークと共有センター] からネットワークアダプターのプロパティを表示させます。

IPv4のプロパティを表示させます。ここではIPv6は無効にしています。

明示的にコンピューターのIPアドレスとデフォルトゲートウェイを設定します。

[閉じる]をクリックすると設定反映が行われるため一瞬RDPが途切れます。設定を間違えると一瞬途切れるどころでは済まなくなりますので慎重に設定しましょう。

2号機も同様に設定します。

OSで明示的にIPアドレスを設定する理由は後続の記事「WSFC設定編」で説明します。

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

2台のインスタンスに、相互で必要なポートが通信可能となるようにセキュリティグループを設定します。
この記事の通りに設定しました。
【EC2】インスタンス間でSQL Server AlwaysOnを構成する際のセキュリティグループ設定

セキュリティグループの設定が完了したら、「1. OS準備編」は完了です。

ワンポイント

上記「EC2インスタンスへのIPアドレス割り当て」手順で、クラスターのリソースやAlwaysOnリスナーとして割り当てられる予定のIPアドレスをあらかじめネットワークインターフェイスに割り当てておりますが、オンプレミス環境でWSFCやAlwaysOnの構築経験がある方にはやや違和感があるかもしれません。(私がそうでした)
VPCではENIに割り当たっていないIPアドレスは他のインスタンスやサービスと通信ができないようです。
私はそれに気づかずに一旦IPアドレスを割り当てないまま手順を進めたところ、AlwaysOn構築手順の完了後、作成されたリスナーに対して自インスタンス以外からアクセスができない事象が発生しました。

AWSのドキュメントでSQL Server AlwaysOnの構築について記載されているのは以下の記事となります。
参考:WSFC ノードでの IP アドレス指定

おわりに

そもそもの話として、わざわざ複数インスタンス間でAlwaysOnを組まなくてもRDS使えば冗長性担保されているよ、という考えもあり、AWSの思想からするとそちらが本筋かもしれません。
それでもRDS移行の前段階として、オンプレミスのAlwaysOnをそのままAWSへ移したい、という要件が時々発生します。そういったケースでお役に立てれば幸いです。

「2.WSFC設定編」(作成予定)へ続きます。

注釈

注1

SQL Server 2016以降のバージョンでは、一部制限があるもののStandard Editionでも「AlwaysOn 可用性グループ」が構築できるようになりました。
参考:基本的な可用性グループ (AlwaysOn 可用性グループ)

注2

「AlwaysOn フェールオーバークラスタインスタンス」はFCやiSCSIを用いて
「2ノードから同時にアタッチ可能でかつ2ノードからは独立した場所にある共有ストレージの存在」
を前提としています。これをAWSで実現するのは追加のリソースが必要となり、難易度も高くなります。


【ALB認証】認証したユーザーをログアウトさせるには

$
0
0

こんにちは、技術4課の城です。
以前、ALB認証の検証ブログを書きましたが、認証したユーザーをどのようにログアウトさせるかについて調べてみました。

ログアウトさせるにはどうするか?

ドキュメントを確認してみたところ、下記の記載がありました。

アプリケーションで認証済みユーザーをログアウトさせる必要がある場合、認証セッション Cookie の有効期限を -1 に設定し、クライアントを IdP ログアウトエンドポイントにリダイレクト (IdP でサポートされている場合) する必要があります。

Application Load Balancer を使用してユーザーを認証する -認証のログアウトとセッションのタイムアウト

認証セッションCookie

認証セッションCookieはデフォルトだと下記のCookieです。

  • AWSELBAuthSessionCookie-0
  • AWSELBAuthSessionCookie-1

ALBのリスナーのルール設定からセッションCookie名を変更できます。
またセッションタイムアウト値もこちらから変更可能です。(詳細後述します)

対象のALBの[リスナー]タブにて、HTTPSリスナーの[ルールの表示/編集]をクリック

上部タブの[編集アイコン]をクリックし、ルールの[編集アイコン]を順にクリック

認証アクションの[編集アイコン]をクリック

[詳細設定]をクリック

赤枠部分がセッションCookie名、セッションタイムアウト値となります。

IdP ログアウトエンドポイント

IdP ログアウトエンドポイントとは??となってしまったので探してみたところ、それらしきドキュメントが見つかりました。
リクエスト例がありましたので、「例 #1: ログアウトしてクライアントにリダイレクトして戻る」で実施します。

GET https://mydomain.auth.us-east-1.amazoncognito.com/logout?
client_id=ad398u21ijw3s9w3939&
logout_uri=com.myclientapp://myclient/logout

ログアウトエンドポイント

なお、各パラメータについては下記となります。

  • client_id
    Cognitoユーザープールに設定しているアプリクライアントのIDです。
  • logout_uri
    アプリクライアントに設定したサインアウトURLを指定します。
    ログアウトした後にリダイレクトさせるURLを指定します。

ログアウトしてみる

Cookieの有効期限を変更する必要があるので、下記のChrome拡張機能を利用しました。
EditThisCookie

まずはログインします。

Cookieを確認します。
EditThisCookieのアイコンをクリックすると、↓のように表示されます。

EditThisCookieではCookieをエクスポート、インポートすることが可能です。
後のテストのためにCookie情報をエクスポートしておきます。

[エクスポートアイコン]をクリックすると、クリップボードにjsonでコピーされます。
メモ帳にでも貼り付けておきましょう。

EditThisCookieを利用して認証セッションCookie 両方の有効期限を -1に変更します。

ログアウトエンドポイントにパラメーターを指定してアクセスさせます。
ブラウザのURL欄に指定したのは下記です。

https://testdomain-jo-auth.auth.ap-northeast-1.amazoncognito.com/logout?client_id=78ltm0ga22i7epc1kume8fs1ap&logout_uri=https://ap01.testdomain-jo.tk/login

ログアウトできました。

セッションタイムアウト値の設定について

ALB認証では ドキュメントにも記載のとおり、ログアウトしたとしても一度認証したユーザーのセッションCookieを再利用することが可能なようです。

実際に試してみます。

EditThisCookieの[インポートアイコン]をクリック

先ほどエクスポートしたCookie情報を貼り付けてインポートします。

認証セッションCookieが設定されているので、ページにアクセスすると、ALBの認証画面が表示されてほしいところですが、Webページが表示されます。

ドキュメントにも下記の記載がありますが、必要最低限の長さで設定する必要がありそうです。

ユーザーが削除された Cookie を再利用しないようにするには、アクセストークンの有効期限を問題のない範囲でできるだけ短く設定することをお勧めします。

さいごに

認証セッションCookieが再利用可能なため、実際にはセッションタイムアウト値を適切に設定することが重要な点について明確に確認できました。

どなたかの助けになれば幸いです。

WorkSpacesの再起動がユーザーで実施できるようになりました!

$
0
0

技術4課のVDIおじさんこと、鎌田です。
WorkSpacesの再起動がユーザー側で出来なくて負担が大きいなぁと思っていた皆様、お待たせしました!
本日のアップデートにて、ついにユーザー側で実施できるようになりました。
このアップデートでは、再起動以外にも、以下のことをユーザーに許可するか、設定が可能になりました。

  • WorkSpacesクライアントに、認証情報を記録する
  • WorkSpacesクライアントから、WorkSpacesを再起動する
  • WorkSpacesクライアントから、ディスクのサイズを大きくする
  • WorkSpacesクライアントから、コンピューティングタイプを変更する
  • WorkSpacesクライアントから、実行モード(AlwaysとAutoStop)を切り替える
  • WorkSpacesクライアントから、Rebuildする

なお、記事執筆時点(2018/11/21)では、WorkSpacesクライアントのみの実装で、Webクライアントでは実行できませんので、ご注意ください。

クライアントから各種の作業を許可する方法

マネジメントコンソールのWorkSpacesの画面を開き、設定変更を実施したいディレクトリを選択して、
「詳細の更新」をクリックします。

「ユーザーセルフサービスアクセス許可」という項目が増えています。

設定項目ごとに、ユーザーに許可するか設定できます。今回は、再起動を有効にしてみます。
有効化をクリックしたら、「更新と終了」をクリックして、設定を保存しましょう。

クライアントで確認してみる

WorkSpacesのクライアントの更新を先に済ませましょう。
WorkSpacesクライアントを起動し、接続してみると、メニューにWorkSpacesの再起動が増えています!

いやいや、素敵なアップデートです。

終わりに

待望のアップデートにより、管理者の運用も楽になるかと思います。
他の機能も、順次試してみたいと思います。

Cloud Automator に新しくジョブの有効期間指定機能を追加しました!

$
0
0

今回のブログでは、本日 Cloud Automator に新しく追加したジョブの有効期間指定機能についてご紹介します。

ジョブの有効期間指定機能をリリース

今までは例えば「ジョブを作成して指定した日からジョブの実行を開始したい」という場合、ジョブを作成後にジョブの状態を OFF に手動で変更して、さらに実行を開始したい日に手動でジョブの状態を ON にする必要がありました。

本日のリリースによってジョブに「有効期間指定機能」が追加され、ジョブの実行を開始する日付と終了する日付をジョブ作成時に指定できるようになりました!

ジョブの有効期間を指定した場合、以下の例のようにトリガーの実行タイミングかつ有効期間内であった場合に、アクションが実行されます。

※ 2018年11月14日現在、有効期間指定機能は「タイマートリガー」のみ対応しています

ユースケース

例えば MSP 事業者など、運用を開始する日がそれぞれ異なるジョブを複数作成したい場合、「運用を開始する当日に手動でジョブの状態を ON にする」という作業をジョブを作成した数だけ繰り返す必要がありました。

そこで、今回リリースされた有効期間指定機能を利用することで「ジョブを作成するタイミングでジョブの実行を開始する日付を指定できる」ため、上記のような人の手に頼った作業を無くし品質の高い運用を実現できるようになります。

ご利用方法

ジョブの有効期間指定機能のご利用方法は こちら にマニュアルを用意しておりますので、ご参考ください。

終わりに

以上、本日リリースしましたジョブの有効期間指定機能をご紹介致しました。
今後のリリース計画については決まり次第、ロードマップページにて公開しております。これからも Cloud Automator をよろしくお願い致します。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

Cloud Automator

AWS SAMでデプロイしてみる

$
0
0

技術課の森です。
そろそろre:Inventですね。
今年は休暇をいただいて参加しますので、見かけられましたら、一声かけてくださいね。

はじめに

今回はAWS SAMを使ってデプロイしてみるところを試してみます。
簡単な構成での作りですので、一度お試ししてもらえればと思います。

準備編

AWS CLIをインストール/初期設定

まずは、AWS CLIをインストールします。
インストールが終わったら、AWS CLIの設定を行っていきます。

S3バケットを作成

デプロイする時に利用するS3バケットを作成します。
今回は、「s3-awssam-samplebucket」とします。

フォルダ構成

取り決めはないのですが、ざっくり以下の感じでフォルダ構成を作成します。

awssam
 ├ src
 | └ app.py
 └ template.yml

ファイル 説明
awssam/src/app.py Lambdaのコードを書きます
awssam/template.yml SAMのテンプレートファイル ここにはAPI Gateway/Lambdaの情報だけを書きます

ファイルの内容

awssam/src/app.py

ここには通常のLambdaコードを書きます。好きなコードを書いて頂ければいいので、ここは割愛します。

awssam/template.yml

このファイルはデプロイする時にメインとなるファイルになります。

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: 'A serverless application that replicate all objects in S3 bucket to Google Cloud Storage.'

Globals:
  Function:
    Runtime: python3.6
    Timeout: 300
    MemorySize: 256

Resources:
  HTTPResponseFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./src
      Handler: app.main
      FunctionName: HTTPAccess
      Role: 
        Fn::GetAtt:
          - SampleLambdaRole
          - Arn
 
  HTTPResponsePermission:
    Type: "AWS::Lambda::Permission"
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref HTTPResponseFunction
      Principal: apigateway.amazonaws.com
 
  HTTPResponseAPI:
    Type: AWS::Serverless::Api
    Properties:
      StageName: Prod
      DefinitionBody:
        swagger: "2.0"
        info:
          title: awssam-apigateway
        schemes:
          - https
        paths:
          /http:
            get:
              summary: "top page"
              description: "http response [top page html]"
              produces:
              - "application/json"
              x-amazon-apigateway-integration:
                  responses:
                    default:
                      statusCode: "200"
                  uri:
                    Fn::Sub: arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${HTTPResponseFunction.Arn}/invocations
                  passthroughBehavior: "when_no_match"
                  httpMethod: "GET"
                  type: "aws_proxy"
        x-amazon-apigateway-policy:
          Version: "2012-10-17"
          Statement:
          - Effect: Allow
            Principal: "*"
            Action: execute-api:Invoke
            Resource:
              - "execute-api:/*"
            Condition:
              IpAddress:
                aws:SourceIp:
                  - "x.x.x.x/32"
  SampleLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: "sts:AssumeRole"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSNSFullAccess
      RoleName: SampleLambdaRole
  NotifySNSTopic:
    Type: 'AWS::SNS::Topic'
    Properties:
      DisplayName: 'AccessNotify'
      TopicName: 'http-access-notify'
      Subscription: 
        -
          Endpoint: mailaddress
          Protocol: email

Globals にPython3.6で、タイムアウト300秒、メモリサイズを256MBで定義、
Resources にはいくつかのAWSリソースを入れてます。
今回は、Lambda/API Gateway/IAM Role/SNSを作っています。
ちなみに、API GatewayはIPアドレス制限をしてみてます。

デプロイ

ここまで用意できたら、後はコマンドを実行して、デプロイします。
カレントディレクトリを「awssam」フォルダとします。

$ aws cloudformation package --template-file template.yml --output-template-file output.yml --s3bucket s3-awssam-samplebucket
$ aws cloudformation deploy --template-file output.yml --stack-name CFnSTACKName --capabilities CAPABILITY_NAMED_IAM

これで、デプロイまで完了です。

さいごに

結構簡単に作り込みもAWSリソースもつくれますし、AWSリソースはCloudFormationテンプレートの書き方でリソースが作れるので、すごく便利ですね。
次回はtemplate.ymlを分けて書いてみることで、Lambda関連の設定とAWSリソースの設定に分離しながら開発できるやり方を書いてみようと思います。

【Alexa】えじこってなぁに? New kokexa dot「ejixa」デビュー! #こけしクイズスキル を作る(1) #Alexa #kokexa #こけし

$
0
0

http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/ejiko_echo_dot3.png
 こんにちは、サーバーワークスのこけしの人、坂本(@t_sakam)です。今回は、10月末に発売された「新しい第3世代のNew Echo Dot」が「あるこけし」に似ていることにインスパイアされて、新しい「kokexa」を作ったので、そのお知らせです。
 上の画像の真ん中にあるのが、その新しいkokexaファミリーの「New kokexa dot」です。またの名を「ejixa」と名付けました。とってもかわいいですね。
 そして、今回は合わせて「こけしクイズ」スキルも作っています。少し長くなってしまうので「こけしクイズ」スキルに関してはブログを分けたいと思います。今回は、第一回目です。

 実は、元々こけしには、上の画像の左右のこけしのように、胴体が丸っこい形のものがあります。この丸っこいこけしは、籠に入った子供を表現しているのですが、こけしが好きな人以外にはあまり知られていないこけしです。

 江戸時代は、子供を「嬰児籠(エジコ)」という籠の中に入れて、農作業をしていたそうです。その籠に入った子供の様子を表現したのが、この「えじこ」と呼ばれるこけしです。

 この「えじこ」は、上の画像のようにちょうど丸みを帯びた新しいEcho Dotのような胴体をしているので、その新しいEcho Dotに「えじこ」こけしの小物入れの蓋を乗せ、「ejixa」にしました。左右の本物の「えじこ」こけしと比べてもなんら違和感のない仕上がりとなっています。

 新しい第3世代のNew Echo Dotは、側面のボディがスピーカーになっているので、ちょうど籠のように見えるのではないでしょうか。なんなら、本物の「えじこ」こけしより「嬰児籠(エジコ)」の「籠感」が表現されている、と言えなくもないです。

 そして、今回も「Alexa Skills Kit SDK for Python」を使って、新しいスキルを作りました。それが、「こけしクイズ」スキルです。「Alexa、こけしクイズをスタートして」と言うと「こけしに関するクイズを出してくれる」というシンプルなスキルです。
 百聞は一見にしかず、ということでまずは完成したスキルの動画をみてみましょう!

動画

 動画内のクイズの2問目にも出てきますが、一番上の画像左の絵付けされていないこけしは岩手県の南部系「えじこ」こけしです。11系統の伝統こけしの中でも、彩色をしないのは、南部系だけとなっています。画像のこけしは、南部系の松田弘次工人のこけしです。

 画像の真ん中の「ejixa」の上部と右の「えじこ」こけしは、津軽系の阿保正文工人のこけしです。

Amazon Developer ServicesのAlexa Skills Kitでスキル作成

スキルの作成

 ここからはスキルの作成です。まずはAmazon Developer Servicesにログインします。[Alexa Skills Kit]タブ – Alexa Skills Kitのトップのスキル一覧ページで[スキルの作成]ボタンをクリックします。
 [新しいスキルを作成]ページでスキル名を「こけしクイズ」、デフォルトの言語を「日本語」に設定します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0001.png
 [スキルに追加するモデルを選択]の箇所では「カスタム」を選択し、[スキルを作成]ボタンをクリックします。

呼び出し名の入力

 左のメニューから[呼び出し名]を選択します。[スキルの呼び出し名]の箇所で「こけしクイズ」と入力します。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0002.png

カスタムインテントを作成

 左メニューの[インテント(3)]の横の[追加]リンクをクリックします。ラジオボタンで[カスタムインテントを作成]を選択します。「KokeshiQuizIntent」と入力し、[カスタムインテントを作成]ボタンをクリックします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0003.png

カスタムスロットタイプを作成

 左メニューの[スロットタイプ(0)]の横の[追加]リンクをクリックします。ラジオボタンで[カスタムスロットタイプを作成]を選択します。「answer_slot」と入力し、[カスタムスロットタイプを作成]ボタンをクリックします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0004.png

スロット値の設定

 作成された「answer_slot」にスロット値を設定します。「このスロットタイプの新しい値を入力」と書かれた入力ボックスに「えじこ」と入力し、右の[+]ボタンをクリックします。続けて、「南部系」と入力し、左の[プラス]ボタンをクリックし、スロット値を設定します。「南部系」の場合は、動画のパターンのように、クイズの回答者が系を付けずに「南部」とだけ回答する場合があるので、「同義語」に「南部」と入れて右の[+]ボタンをクリックします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0005.png
 ここではクイズの答えとなる文言を入れているので、動画内に出てくるクイズ以外の他のクイズの回答も続けて入れていきます。上のキャプチャ画像では、津軽系と作並系と入れてあります。

インテントスロットとサンプル発話の設定

 [インテントスロット]一覧の1番目の「新しいスロットを作成」と書かれた入力欄に「AnswerSlot」と入力し、[+]ボタンをクリックします。左のスロットタイプは先程作成した「answer_slot」を選択します。

 上のサンプル発話は「このインテントの呼び出しに使われると考えられる発話」と書かれた入力ボックスに「{AnswerSlot}」と入力し、右の[+]ボタンをクリックします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0006.png

スキルIDをコピー

 左メニューから[エンドポイント]を選択します。ラジオボタンで[AWS LambdaのARN]を選択します。すると、このスキルのスキルIDが表示されます。あとで使うので、コピーして控えておきます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0007.png

モデルの保存とビルド

 ここまでできたら、いったんモデルの保存とビルドをおこなっておきます。上の方にある[モデルを保存]ボタンをクリックします。保存が終わったら、[モデルをビルド]ボタンをクリックします。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/Alexa_Skills_Kit_0008.png
 「Alexa Skills Kit SDK for Python」がまだ出てきていませんが、第一回目は、ここまでとなります。

まとめ

 今回は、「New kokexa dot」(またの名を「ejixa」)の発表と、「Alexa Skills Kit SDK for Python」を使って「こけしクイズ」スキルを作る、の第一回目でした。

 いや〜、ASK SDK for PythonとNew Echo Dotって本当にいいものですね!

LambdaでPHPが動いた! PHP Layer For AWS Lambdaを使って、kokexaの画像を動的にランダム表示 #reInvent #kokexa #lambda #php

$
0
0

http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/kokexa_top.png
 こんにちは、サーバーワークスのこけしの人、坂本(@t_sakam)です。
 
 re:Invent 2018のキーノートでLambdaの「Custom Runtimes」と「Layers」が発表されました。これにより、AWS公式での言語サポートではありませんが、パートナーの「Stackery」が公開している「PHP Layer For AWS Lambda」を使うことで、LambdaPHPが使えるので、簡単に試してみたいと思います。
 
 LambdaとPHPを使って、先日デビューした「New kokexa dot」、通称「ejixa」の画像を動的にランダム表示するページを作ってみたいと思います。

New kokexa dotについてはこちら

【Alexa】えじこってなぁに? New kokexa dot「ejixa」デビュー! #こけしクイズ スキルを作る(1) #Alexa #kokexa #こけし

手順

 「PHP Layer For AWS Lambda」に書いてある手順を参考に、足りないところは足しつつ進めてみます。

PHPをインストール

 開発環境のEC2にPHPが入っていませんでしたので、yumでインストールします。バージョンは、7.1です。

$ sudo yum install php71

SAMをインストール

SAMも使ったことがなかったので、インストールします。

$ pip install --user aws-sam-cli

デプロイ用のS3バケットを作成

$ aws s3 mb s3://kokexa-php --region ap-northeast-1

開発用のディレクトリを作成して中へ

$ mkdir kokexa-php
$ cd kokexa-php

template.ymlファイル作成

 中身は、「PHP Layer For AWS Lambda」に載っているtemplate.ymlそのままです。

$ vim template.yml

AWSTemplateFormatVersion: 2010-09-09
Description: My PHP Application
Transform: AWS::Serverless-2016-10-31
Resources:
  phpserver:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub ${AWS::StackName}-phpserver
      Description: PHP Webserver
      CodeUri: src/server
      Runtime: provided
      Handler: index.php
      MemorySize: 3008
      Timeout: 30
      Tracing: Active
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:887080169480:layer:php71:3
      Events:
        api:
          Type: Api
          Properties:
            Path: /{proxy+}
            Method: ANY

以下の構造になるようにディレクトリを追加

kokexa-phpディレクトリの構造

├── template.yaml
└── src
    └── server
        └── index.php

index.phpの作成

$ vim src/server/index.php

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>kokexa-php</title>
  </head>
  <body>
    <h1>New kokexa dot</h1>
<?php
$url = "https://s3-ap-northeast-1.amazonaws.com/xxx-xxx/";

$img01 = $url . "kokexa_01.jpg";
$img02 = $url . "kokexa_02.jpg";

$img = array($img01, $img02);
$rand = rand(0, 1);
?>
    <img src = <?php echo $img[$rand]; ?>>
  </body>
</html>

 「xxx-xxx」というS3バケットにkokexaの画像が2枚置かれているイメージです。この2つをランダムに切り替えます。

デプロイ

$ sam package \
    --template-file template.yaml \
    --output-template-file serverless-output.yaml \
    --s3-bucket kokexa-php

$ sam deploy \
    --template-file serverless-output.yaml \
    --stack-name kokexa-php \
    --capabilities CAPABILITY_IAM

アクセス

 API Gatewayのマネジメントコンソールで発行されたURLを確認して、アクセスしてみます。
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/api.png
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/new_kokexa_dot_01.png
http://corporate-tech-blog-wp.s3-website-ap-northeast-1.amazonaws.com/tech/wp-content/uploads/2018/11/new_kokexa_dot_02.png
 「https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/Prod/index.php」にアクセスすると、S3に置かれた2枚のkokexaの画像のどちらかが表示されるようになりました。
 

まとめ

 今回は、「PHP Layer For AWS Lambda」を使って、LambdaでPHPを動かしてみました。これで、新しいkokexa dotの画像を簡単にランダムに表示できるようになりましたね!

 PHPはHTMLの中に簡単にコードを入れられるので、今回のようなちょっとした動的ページがこれからはLambdaでサクッと作れますね!

 いや〜、「PHP Layer For AWS Lambda」って本当にいいものですね!

SORACOM LTE-M Button powered by AWS 「ご購入、利用開始方法」のチュートリアル #SORACOM

$
0
0

本記事は「SORACOM LTE-M Button powered by AWS Advent Calendar 2018」12月2日(日)の記事です。
https://qiita.com/advent-calendar/2018/soracom

SORACOM LTE-M Button powered by AWSのサイトに載っている「ご購入、利用開始方法」のチュートリアルをご紹介します。「ご購入、利用開始方法」は以下URL掲載されています。
https://pages.soracom.jp/LP_SORACOM-LTE-M-Button.html

ご購入、利用開始方法

1. SORACOMウェブコンソールから商品を購入します(SORACOMアカウントをお持ちでない方はこちらから)
2. AWSアカウントを作成します
3. AWS IoT 1-Clickからデバイス登録をします
4. AWS IoT 1-Clickにプロジェクトを作成後、デバイスのプレイスメントテンプレートを作成してアクションを設定します。アクションは、予め用意されているLambda関数(SMS送信、Eメール送信)をプルダウンで選択できるほか、任意のLambda関数 (Node.js、Java、C#、Go および Pythonで記述可能)を設定できます。
5. さあ使ってみましょう! SORACOMアカウントに本ボタンを登録する事で、残りの契約期間やクリック数の閲覧、契約更新が可能です。

本記事では1.および2.は完了しているものとして、3.〜4.のステップをご紹介します。AWS マネジメントコンソールでのAWS IoT 1-Clickの設定が中心になります。(以降のスクリーンショットはクリックして拡大することが可能です)

AWS IoT 1-Clickからデバイスを登録

AWS マネジメントコンソールからIoT 1-Clickを探してクリックしてください。検索ウィンドウで「iot」と入力すると探しやすいと思います。

IoT 1-Clickの画面に移ったら「デバイスの登録」をクリックしてください。

デバイスIDを入力します。デバイスIDはLTE-M Button背面の電池カバーを外したところに記載の「DSN:」以降の英数字を指します。

デバイスからの応答が必要になります。この画面になったらLTE-M Buttonのボタンを1回押してください。

デバイスのボタンが押されると以下のような画面に変わります。これで登録済みの状態になりました。

デバイス一覧に表示されています。この時、デバイスリージョンは必ずus-west-2になります。これはAWS IoT 1-Clickをどのリージョンで利用しても同様にそうなります。本記事執筆時点のAWS IoT 1-Clickの仕様となりますので、気にせずこのまま進めていってください。また、デバイスの状態が「無効」になっていますが、このあとの工程で自動的に有効化されます。(この画面で有効化することも可能です。もし、なにかの理由でうまくいかない時はデバイスの状態が有効になっているかどうか確認してみてください)

(中略)AWS IoT 1-Click デバイスは証明書が事前にプロビジョニングされた状態で出荷され、特定の AWS リージョンに登録されています。AWS IoT 1-Click サービスの料金は、デバイスが登録されている AWS リージョンとは関係ありません。現時点では、すべてのデバイスが米国西部 (オレゴン) リージョンに登録されます。
https://aws.amazon.com/jp/iot-1-click/pricing/ より引用

プロジェクトの作成

ここからはAWS IoT 1-Clickにプロジェクトを作成していきます。「プロジェクト」をクリックしてください。

「プロジェクトの作成」をクリックしてください。

「プロジェクト名」に任意の文字列を入力して「次へ」をクリックしてください。

デバイステンプレートを定義します。「開始」をクリックしてください。

テンプレートのデバイスタイプの選択欄が出ますのでクリックしてください。

ここではボタンを押したらSMSを送信する機能とします。「デバイステンプレート名」に任意の文字列を入れてください。「アクション」はデフォルトのまま「SMS を送信する」にしておいてください。

画面下部に電話番号とSMSメッセージを入力する欄があります。電話番号は日本の国番号(+81)から入力してください。(例:090-XXXX-XXXXという電話番号であれば、090の先頭0を除いて+8190XXXXXXXXと入力してください)メッセージは任意も文字列で入力してください。いずれも入力できたら「プロジェクトの作成」をクリックしてください。

プレイスメントの作成

プロジェクトの準備が完了したら「プレイスメントの作成」をクリックしてください。

「デバイスのプレイスメント名」に任意の文字列を入力します。次に先程作ったテンプレートにデバイスを関連付けるため、「選択」をクリックしてデバイスを選択してください。

この画面のようになったら画面下部にある「プレイスメントの作成」をクリックしてください。

この画面になったらAWS IoT 1-Clickの設定は完了です。さあ、ボタンを押してみましょう!

さあボタンを押してみましょう!

登録した電話番号にSMSが届けば成功です。おめでとうございます!もし、うまくいかない場合は以下のことを確認してみてください。

  1. ボタンを押した時にエラーを示す赤点灯していないか
  2. ボタンがAWS IoT 1-Clickの設定上、有効になっているか
  3. ボタンがテンプレートに関連付けられているか(プレイスメントの作成)

参考情報

SORACOM : https://soracom.jp/
AWS IoT 1-Click : https://aws.amazon.com/jp/iot-1-click/
前日12月1日(土)の記事はコチラ


新機能VPC Sharing(Shared VPC)のドキュメントを読んでみる

$
0
0

プロフェッショナルサービス課の杉村です。re:Invent 2018では数々のアップデートや新サービスが発表されましたね。
機械学習系のサービスやよりスマートに開発をするためのサービスが次々発表されましたが、多くのエンタープライズクラスのお客様とお付き合いをさせていただいている私には、AWS Control TowerAWS Transit Gatewayなど管理系・ネットワーク系の新サービスが大変魅力的に映りました。

ネットワーク系のリリースに関しては、下記のセッションの動画が分かりやすいですね。

動画でも紹介されていますが、ちょっと地味ながらも光る新機能が発表されました。

Working with Shared VPCs
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html

VPC SharingまたはShared VPCと呼ばれる、VPCの新機能です。
なんとあるAWSアカウント内のサブネットを別のAWSアカウントにシェアできる、という機能です。

あるAWSアカウントに存在するEC2やRDSに別のAWSアカウントからネットワーク的にアクセスするには、従来ですとVPC Peeringが必要でした。
2つ目のAWSアカウントにVPCを作ってPeeringするには、1つ目のAWSアカウントのVPCと被らないIPアドレス帯を払い出す必要があります。

しかしVPC Sharingの機能を使えば、下記のようにAWS Account間でVPC内のサブネットをシェアできるのです。

まだ詳細は未検証ですが、ドキュメントから読み取れる仕様をメモいたします。(英語版しかないので、備忘がてらに…)

前提

サブネットをシェアするには同じAWS Organizationsに所属している必要があります。
私たちのようなパートナー経由でAWSをご利用いただいているお客様は特に上記の点で注意が必要ですため、ご利用いただけるかどうかはパートナーにご相談ください。

またデフォルトVPC内のサブネットはシェアできません。

シェアする方法

まず AWS Resource Access Manager でResource Share(シェアの設定の概念)を作成します。ここでシェアする先のAWSアカウントやサブネットなどを指定します。
シェアするVPC・サブネットのオーナーAWSアカウントで、サブネットをシェアします。
(マネコンならVPC>Subnets>Actionsボタン>Share subnet)
そしてResource Shareを選択してShare subnetを押下します。

これでシェアが完了です。
シェアした先のAWSアカウント(Participantとします)のVPCのサブネット一覧に表示されるはずです。
サブネットにはOwnerという属性が表示されるようになっており、親(Ownerとします)が誰かが分かります。

参考 AZについて

AWSではあるAWSアカウントの「us-east-1a」は別のAWSアカウントでは「us-east-1b」かもしれないという、AWSアカウントごとにAZ名と実態が異なる場合がある、という仕様があります。
そのためAWSアカウント間で正しくAZを特定するには、AZ IDというAZに固有なIDを使います。(このIDは以前は見えませんでしたが現在は表示されるようになりました)

できること

Ownerができること

当然ですがサブネットの作成・削除・変更、そしてRoute Table、IGW、NAT GW、VPC Peering、PrivateLinkなどの各種VPCレベルのリソースの作成・削除・変更ができます。
ただしシェアされたサブネットにParticipantが作ったSecurity Group、EC2、RDSなどのリソースは削除ができません。(閲覧はできます)

Participantができること

シェアされたサブネットの中で EC2, RDS, Redshift, Lambda などが利用できます。
当然他のParticipantのリソースは見えませんし触れません。 Route table や NACL は閲覧できますが、変更できません。(VPCレベルのリソースは触れない)
Security Group IDを使えば、他のParticipantやOwnerのSecurity GroupをSGのレコード内で参照できます。
VPC Flow Logsの作成ができます。

料金について

EC2やRDSなど、作ったリソースの料金はParticipantにかかります。AZ間のdata transfer料金やVPC Peeringのdata transfer料金、Direct Connect gatewayのdata transfer料金もParticipantです。
一方でNAT Gateway、VGW、Transit Gateways、PrivateLink、VPC Endpointsの時間料金、データ容量やdata transfer料金はOwnerが払います。

対応していないサービス

シェアしたサブネットでは以下のサービスは利用できません。

Amazon Aurora Serverless
AWS Cloud9
AWS CloudHSM
AWS Glue
Amazon EMR
Network Load Balancer

制限

同じAWS Organizationに所属している必要があります。
default VPCはシェアできません。
Participantは他のParticipantやOwnerのSecurity Groupを使ってリソースをローンチできません。
ParticipantはDefault Security Groupを使ってリソースをローンチできません。

まとめ

エンタープライズクラスのAWSご利用者様の場合、IPアドレス帯の管理やセキュリティポリシーの関係で、AWSアカウントを分けてもその新しいアカウントの中にVPCを新規作成して既存のAWSアカウントとVPC Peeringで繋いで・・・ということにハードルがある場合があります。そんな場合にこの機能を使えば、既存のVPCを利用し、かつAWSアカウントとしての権限分離もできます。
検証をしてみたうえで、さらなる情報はまたブログにしようと思います。

AWS re:Invent 2018 Andy Jassyさん基調講演の文字起こしとそのアーキテクチャ #reInvent

$
0
0

AWS re:Invent 2018で発表のあったAndy Jassyさんの基調講演を文字に起こしました。そのファイルをダウンロード可能にしています。また、AWSを使ってどのように文字起こしを実現したのかについても触れています。メディア分析の一例として、みなさんの参考になれば幸いです。

Andy Jassyさん基調講演の文字起こし

re:Invent 2018でのAndy Jassyさんの基調講演がYouTubeにアップロードされています。その全文を文字起こししプレーンテキストでファイルを作成しました。ファイルは以下のリンクからダウンロードできます。

AWS_reInvent2018-Keynote-with-Andy-Jassy.txt

元となった動画は以下でご覧になることができます。

文字起こしするあたって

なぜ?おこなったのか

それはre:Invent 2018を日本に居ながら楽しみたかったからです。re:Inventは米国で行われるイベントですがビジネス、エンジニアリングといった様々な視点から楽しめるイベントです。「現地と日本、みんなで新しい技術を楽しむ」というテーマの中で、社内のみんなとディスカッションした中で出てきたアイディアの1つがこの文字起こしです。

アーキテクチャの検討

真っ先に思い浮かんだのがAmazon Transcribeの利用です。Amazon Transcribeは音声ファイルをテキスト化するAWSサービスです。以下のような構成図でシステム化を検証しました。(2018年10月にre:Inventに向けて準備をしはじめました)

S3バケットに音声ファイルを入れると自動的に文字起こしされ、プレーンテキストが作成されるというものです。このシステムは期待した動作をしましたが、S3バケットに置かれるものが各種メディアファイル(音声以外の動画等)に対応していないことや、音声ファイルがmp3でサンプリングレートが22.05KHzに限定されている課題がありました。そこで、機能拡張を検討していましたが、欲しいものがすべてそろったリファレンス実装がAWS社から紹介されていました。

実際に利用したシステム

AWS Answersで紹介されていた「メディア分析ソリューション」を用いました。以下に構成図と機能概要を引用しますが、これらの機能がCloudFormationのテンプレートで提供されています。ユーザーインターフェイスとしてWeb画面も用意されているため、誰でも簡単にメディア分析を試すことができます。

1.Amazon Simple Storage Service (Amazon S3) メディア分析バケットに新たにメディアファイルがアップロードされると、AWS Lambda 関数が AWS Step Functions ステートマシンを呼び出します。メタデータは Amazon Rekognition、 Amazon Transcribe、Amazon Comprehend によって抽出されます。

2.MP4 動画ファイルがアップロードされると、AWS Elemental MediaConvert は Amazon Transcribe と Amazon Comprehend による分析のための音声を抽出します。

3.別の Lambda 関数が Amazon S3 バケットと Amazon Elasticsearch クラスターに結果を取得して、処理、格納します。生成されたメタデータは、Amazon Cognito と Amazon API Gateway RESTful API を使用して、認証、安全検索、取得が可能です。 

4.このソリューションには静的な Amazon S3 ウェブインターフェイスもデプロイされており、お客様はアップロード、分析、小さなメディアファイルのやり取りをすぐに始めることができます。 

メディア分析ソリューションを使ってYouTubeの動画を分析する

メディア分析ソリューションには動画ファイルや音声ファイルが必要です。今回対象としたメディアはYouTubeの動画だったため、まずは動画ファイル化もしくは音声ファイル化する必要がありました。今回は音声ファイル化することを選択し、以下の方法で分析を行いました。

  1. iPadとサウンドレコーダー機器をライン接続する
  2. 動画をiPadのYouTubeアプリで再生し、サウンドレコーダー機器で録音・音声ファイル化する
  3. 2.の音声ファイルをパソコンに移し、2時間以内のファイルに分割する(※)
  4. 3.で分割されたファイルをそれぞれ、メディア分析ソリューションを用いてテキスト化する

(※)メディア分析ソリューションで使われているAmazon Transcribeには本記事執筆時点で「最大2時間まで」という制限があります。2時間を超えるファイルは分析に失敗します。今回の対象は2時間40分の講演でしたので、2つのファイルに分割しました。分割する際には話している途中で切れないように波形編集ソフトを用いて確認しながら行いました。今回は1時間39分15付近、ちょうどRoss Brawnさんにスピーカーが交代するところで分割しました。 また、メディア分析ソリューションのWeb画面から登録できるファイル容量が100MBに制限されています。コードを書き換えたりすることで制限を解除することもできるとは思いますが、今回は音声ファイルをモノラル化するのと、ビットレートを落とすことでファイル容量を落とし対応しました。(Web画面仕様に容量制限があるだけで、直接S3バケットにアップロードしてメディア分析する方法もメディア分析ソリューションには用意されています)

1.〜4.いずれもAWSを駆使することでシステム化できる部分があると思いますが、今回は4.の工程のみをAWS上にシステム化して対応しました。

参考情報

Amazon Transcribeの制限:https://docs.aws.amazon.com/ja_jp/transcribe/latest/dg/limits-guidelines.html

AWS Answers「メディア分析ソリューション」:https://aws.amazon.com/jp/answers/media-entertainment/media-analysis-solution/

AWS公式サイト(re:Inventの新着情報がまとまっています):https://aws.amazon.com/jp/

DX系サービスの変遷とAWS Transit Gatewayの嬉しいところ

$
0
0

杉村です。re:InventでAWS環境のネットワークアーキテクチャを大きく変えるサービスがローンチされました。
既に随所で話題になっているAWS Transit Gatewayです。
概要はAWSの公式発表や各社のブログで明らかになっていますので、私は「今までと何が違うの?どうして嬉しいの?」にフォーカスして考えてみたいと思います。

参考
新機能 – トランジットゲートウェイでネットワークアーキテクチャをシンプルに
AWS Transit Gateway

できること

まず簡単に言うと、下記のようなネットワーク構成が可能になります。

今までとちがうところ

特にDirect Connect(以下、DX)をご利用の方向けに、以下にAWSサービスの変遷を記載します。

すごく以前(2017/10以前)

DXを引いたら、全てのVPCのVGWに対してVirtual Interface(以下、VIF)を紐づけなければいけませんでした。
そのたびにルータの管理をしている業者に作業を依頼しなければいけない場合もお客様によってはあったと思います。またルータの機種によっては再起動が必要とされ瞬断が起きたりしていました。
当然、VPC同士はVPC Peeringで相互に繋いでいなけば通信できません。

ちょっと以前(2017/11以降)

Direct Connect Gateway(以下、DXGW)がリリースされました。
各VPCに対してVIFを作らなくても、DXGWに対してVIFを紐づければ、あとはDXGWから各VPCに接続できるようになりました。
これでルータ管理をしているベンダへの作業依頼は不要です。
しかもリージョンをまたいで接続が可能になります。
ただし現在のところ、DXGWから接続できるのは同じAWSアカウントの中のVPCだけです。
またDXGWに紐づけられたVPC同士の通信もできません。
(すべてのVPC間で通信できるようにするにはVPC Peeringをフルメッシュで繋ぐ必要がありました)

AWS Transit Gateway以降(2018/12以降)

AWS Transit Gateway(以下、TGW)がリリースされました。
TGWに接続されているVPN、DXGW、VPC同士が相互に接続可能になります。
(残念ながら現在はVPCとVPNのみ。DXは来年対応予定)
内部に複数のルートテーブルを持ちVPCやVPNごとに関連付けを指定できるので、セグメント化が可能です。
(VPC01とVPC03は相互にアクセスさせたくない、といった制御が可能)

今後に期待

VPCがどんどん増えていき100, 200となったときにフルメッシュのVPC Peering運用はワークしません。
そもそもルートテーブルのルール数上限にひっかかるし、大変すぎます。(Peeringが n*(n-1)/2 の数になってしまいますからね。)
前述のように少ない労力で、かつ細かい制御が可能になった点が大きく違うということです。

残念ながら肝心の東京リージョンにはまだリリースされていませんが、Direct Connectへの対応と併せて、期待が高まります。

AWS 中国リージョンのお話

$
0
0

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

訳あってAWS 中国リージョンを触る機会がありまして、その際に気付いたAWSとAWS 中国リージョンの違い(2018年12月時点)をメモしていきます。

アカウント発行は…

そう、そもそも中国の法人がないと、アカウントが発行されず利用できません。グローバルに展開する企業さんであれば、たいてい中国に現地法人があるので、その中国法人からAWS中国に利用を申し込むとよいでしょう。

グローバルサービスが…

そう、IAMのみ利用できす。通常のAWSでもリージョンにより利用できるサービスが異なりますが、Route53やCloudFrontなどのグローバルサービスはどのリージョンでも利用できます。しかしAWS中国の場合は、Route53やCloudFrontのグローバルサービスが利用できませんので注意が必要です。もちろん、AWS中国内でも北京リージョンか寧夏リージョンかによって、その他のサービスも利用できる/できないがあります。

スイッチロールしたい…

通常のAWSとAWS中国は完全に分離されているようなので、通常のAWSからAWS中国へのスイッチロールはできません。AWS中国から同じくAWS中国へのスイッチロールは可能です。

ドメインが…

そう、違います。
通常のAWS(東京リージョン)↓

AWS中国↓

通常のAWSとAWS中国は完全に分離されているようなので、通常のAWSのマネコンと中国リージョンのマネコンは同時に開くことが可能です。

ARNが…

そう、ドメインと同様ARNも違います。ARNに-chが含まれます(画像はIAM Roleの例)。IAMポリシーやCFnテンプレートでARNを指定する際は注意が必要です

IAMロールの信頼関係…

そう、ARNと同じようにchが含まれるものがあります。そして含まれないものもあります。注意が必要です。

まとめ…

以上、AWSとAWS中国の違いメモでした。その他にも違う点があるかもしれませんので、発見次第更新したいと思います。もし利用される機会があれば事前調査をすることをお勧めします。

ちなみに…

Webinerが実施されているようです。資料も公開されているようです。興味があればぜひ。

AWS Lambda Layers でライブラリを共通化する

$
0
0

はじめに

こんにちは、技術一課の山中です。

re:Invent 2018 にて AWS Lambda Layers が発表されました!

新機能 – AWS Lambda :あらゆるプログラム言語への対応と一般的なコンポーネントの共有 | Amazon Web Services ブログ

例えば ロギングモジュール等、今まで複数の Lambda ファンクションから呼び出すライブラリがあっても各ファンクションごとにパッケージングする必要がありました。
今回発表された AWS Lambda Layers を利用することで共通モジュール / 共通処理を Layer 化して複数の Lambda ファンクションから利用することができるようです。

というわけで、早速試していきます。

共通プログラム作成

今回は試しに、ロギング部分と Amazon SNS によるメッセージング部分を Layer として共通化してみたいとおもいます。
実際に書いた Python ファイルはそれぞれ以下のとおりです。

log.py

import logging


# ログオブジェクト作成
def get_logger(workername, loglevel):
    # ログの出力名を設定
    logger = logging.getLogger(workername)
    # ログレベルの設定
    logger.setLevel(int(loglevel))

    log_handler = logging.StreamHandler()
    logger.addHandler(log_handler)

    # ログの出力形式の設定
    log_handler.setFormatter(
        logging.Formatter('%(asctime)s, %(process)d, %(levelname)s, %(message)s')
    )

    return logger

sns.py

import boto3


# sns 接続
def get_sns_client():
    return boto3.client('sns')


# SNS メッセージ送信処理
def publish_message(topic_arn, subject, message):
    client = get_sns_client()
    client.publish(
        TopicArn=topic_arn, 
        Subject=subject,
        Message=message,
    )

log.py がロギング用、 sns.py が SNS によるメッセージング用となります。
作成した Python ファイル及びライブリ群を以下のように zip ファイルにまとめます。

layer.zip
│ python/log.py
│ python/sns.py
└ python/lib/python3.7/site-packages/[libraries]

この作成した zip ファイルを Lambda Layer として登録していきます。

Lambda Layer の作成

Lambdaのコンソールから [Layers] を選択し、 [Create layer] ボタンをクリックします。

Layer 作戦画面にて先程作成した layer.zip ファイルをアップロードし、適当な名前を付け作成します。

これで Layer が完成です。簡単ですね!

Lambda ファンクションの作成

Layer を利用して Lambda ファンクションを作成していきます。

今回はランタイムを Python 3.7 、 IAM Role として SNS へのフルアクセスポリシーを持つロールを選択しました。

作成が完了したら、 [Layers] を選択後 [Add a layer] ボタンをクリックします。

先程作成した Layer を選択し、 [Add] ボタンをクリックします。これだけで、 Layer の追加は完了です。

次にメインの Lambda ファンクションのコードを書いていきます。

今回は以下のような簡単なコードを書いてみました。

from log import get_logger
from sns import publish_message

# ログの出力名を設定
logger = get_logger('sample-function', 20)


def lambda_handler(event, context):
    logger.info('input event : {}'.format(event))

    logger.info('Start send message')
    publish_message(
        'arn:aws:sns:ap-northeast-1:000000000000:dev',
        'Test Subject',
        'Test Message',
    )
    logger.info('Finish send message')

コードの 1 行目及び 2 行目で Layer から利用する機能をインポートしています。

後は [Save] ボタンをクリックして作成完了です!

試してみる

では早速テストしていきましょう。
適当にテストイベントを作成します。

[Test] ボタンをクリックします。

インポートエラーも起こさず、きちんとログが出力されています!

メールはどうでしょうか。

きちんと届いています!

おわりに

コードの共通化が AWS Lambda Layers を利用すると簡単に実装できました。
ロギング等ほとんどのファンクションで利用するコードを共通化することで、メインのコードに集中及び簡素化することができます。

Layer 化する単位や関数等はプロジェクトによって、考慮する必要はありますがどんどん使っていきたいですね!

Viewing all 1210 articles
Browse latest View live


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