読者です 読者をやめる 読者になる 読者になる

先週のAWS関連ブログ 〜4/10(日)

AWS AWS - アップデートまとめ

どうも、セクションナイン吉田真吾@yoshidashingo)です。

息子の学校や娘の幼稚園が始まり、また忙しい日々が戻ってきた感じです。子どもの成長は早いですね。 それでは行ってみましょう。

AWS公式

1. Amazon Route 53でメトリクスベースのヘルスチェック、プライベートホストゾーンのDNSフェイルオーバー、設定可能なヘルスチェックロケーションがアナウンスされました

f:id:yoshidashingo:20160411091701p:plain

  • また、Route 53のヘルスチェックでエンドポイントを指定する場合に、今までのすべてのリージョンからのヘルスチェックでなく、どのリージョンからヘルスチェックを行うか選択できるようになった。

f:id:yoshidashingo:20160411091718p:plain

2. AWS Config Rulesが新しく4つのリージョンで利用可能になりました

f:id:yoshidashingo:20160411092608p:plain

  • 現在のところ組み込みで7ルールが用意されている様子。

f:id:yoshidashingo:20160411094137p:plain

3. Amazon RDS for PostgreSQLで PostgreSQL 9.5(9.5.2)とバージョン9.4.7、9.3.12サポート

  • リンク:Amazon RDS for PostgreSQLで PostgreSQL 9.5(9.5.2)とバージョン9.4.7、9.3.12サポート | Amazon Web Services ブログ
  • RDS for PostgreSQLの新しいマイナーバージョン9.5系にも対応して、「UPSERT」「Row Level Security (RLS):行や列レベルのアクセスコントロール」「Big Data features」に対応した。
    • UPSERT:主キーに対応するデータがあればUPDATE、なければINSERT
    • Row Level Security (RLS):今までVIEWなどを使って実現してきた個人情報などを扱う際にDB接続ユーザーによって特定の列を見せないといった制御がテーブル側にできるようになった
    • Big Data features:
  • 9.5.2のサポート意外に、9.4系は9.4.7、9.3系は9.3.12をサポートしたことでautovacuumのステータスが参照可能になった。

f:id:yoshidashingo:20160411094447p:plain

4. AWS LambdaでNode.js 4.3.2が利用可能になりました

  • Node.js 4.3.2が利用可能になった。
    • Node.js 0.10のEOLが2016年10月にくることを見据えるとプロダクションコードがあれば移行を検討する必要がある。
    • 非同期処理にPromiseが利用可能になっており、無料で読める「JavaScript Promiseの本」がオススメされている。

aws.typepad.com

5. Pipeline スターターキットで、AWS 上での継続的デリバリーをお試し

  • CloudFormationで構築する、GitHubからソースを取得してJenkinsでビルドして、まずBetaサイトのEC2インスタンスに、次に本番用EC2インスタンスにデプロイするCodePipelineを構築するサンプルキット。

aws.typepad.com

6. AWS Black Belt Online Seminar 「Lumberyard」資料公開

  • LumberyardとGameLiftの日本語資料が結構少ないなか、まとまったものとして貴重な資料

aws.typepad.com

www.slideshare.net

7. AWS Elastic Beanstalkに2つのデプロイメントポリシーが追加され、Amazon Linux AMI 2016.03にも対応

  • 追加された1つめのデプロイメントポリシーは、イミュータブルなデプロイをする際に、新しいスタックをフルセットの台数で準備せず、まず1台作成してヘルスチェックOKだったらフルセットの台数で新しいスタックを作成してスワップする方法。これで新しいスタックがヘルスチェックNGでもフル台数分の課金がされずに済む。
  • 追加された2つめのデプロイメントポリシーは、ローリングアップデートする際に、アップデートにより切り離されるリソースによりスタックのトータル処理能力が落ちたり、アップデートに失敗したときに素早く元のスタックに戻れるように、ローリングアップデートに入る台数分の新しいリソースを作成して古いバージョンを最後まで残しておくというもの。たとえばスタックが9台で3台ずつローリングアップデートする場合、3台の新バージョンのリソースを作り、ヘルスチェックOKなら新しい3台にトラフィックを流し、次の3台からはスタックから切り離してアップデートを行うことで常に9台でトラフィックをさばく方式。
  • ソース:AWS Elastic Beanstalk Adds Two New Deployment Policies and Amazon Linux AMI 2016.03 Update

8. AWS Directory Serviceのコンソールで信頼関係の構築が簡単にできるように

9. EC2 Run Commandに定義済みコマンドの追加とエージェントをオープンソースに

  • EC2 Run Command for Windows に2つのコマンド「オンデマンドパッチ」「インベントリ情報収集」を追加した
    • オンデマンドパッチ:あたってないアップデートを見つけてアップデートする
    • インベントリ情報収集:OS情報やインストール済みのプログラム、あたっているWindowsアップデートのバージョン情報などを収集する
  • 管理者の作業がこれでだいぶ楽になるはず
  • ソース:EC2 Run Command adds support for more predefined commands and announces open source agent

10. Amazon Machine Learningの学習モデルをシャッフルするように改良

AWS関連

11. AWSアカウントとVPC、分ける? 分けない?: 分割パターンのメリット・デメリット

  • 運用上、環境によりアカウントを分けることが多いが、その方式ごとのメリデメ比較

dev.classmethod.jp

その他

12. LINE Bot API関連

先週ベータ公開されたLINE Bot APIをさっそく試した記事がたくさん上がっています。中でもいくつかの記事で、callback URLがHTTPS必須なのでAPI Gatewayをフロントに置き、BotをLambdaで実装するのが比較的簡単な方法として上がってますが、ここでポイントとなるのがLINE Bot API側ではBotのIPアドレスをホワイトリストとして登録する必要があり、その範囲が連続したセグメントとして登録しないといけない点(サブネットマスク=24〜30)。Lambdaの、というかAWSのPublic IPは都度かなり広い範囲からランダムに払い出されるし、Lambdaは永続化の保証がないので、ホワイトリストのメンテナンスが必要になってしまう点がちょっと困り者。ということでおそらくLambdaをVPCにデプロイして、0.0.0.0/0をNAT Gatewayに向ければIPの固定化ができると思いますが試してないので誰かお願いしますって感じです。

f:id:yoshidashingo:20160411103554p:plain

qiita.com

ということで今週は以上です。