どうも、セクションナイン の 吉田真吾(@yoshidashingo)です。
息子の学校や娘の幼稚園が始まり、また忙しい日々が戻ってきた感じです。子どもの成長は早いですね。 それでは行ってみましょう。
AWS公式
1. Amazon Route 53でメトリクスベースのヘルスチェック、プライベートホストゾーンのDNSフェイルオーバー、設定可能なヘルスチェックロケーションがアナウンスされました
- リンク: Amazon Route 53でメトリクスベースのヘルスチェック、プライベートホストゾーンのDNSフェイルオーバー、設定可能なヘルスチェックロケーションがアナウンスされました | Amazon Web Services ブログ
- Route 53のヘルスチェックに「CloudWatch alarm」を設定できるようになった。
- CloudWatch alarmを利用し、今までのRoute 53のヘルスチェック機能として代表的なエンドポイントへのヘルスチェックではチェックできなかった内容でヘルスチェックおよびフェイルオーバーの設定ができるようになった。
- 下のRoute 53画面は、CloudWatchで設定したインスタンスのCPUクレジットのアラームをトリガーに利用してフェイルオーバーする設定。
- また、Route 53のヘルスチェックでエンドポイントを指定する場合に、今までのすべてのリージョンからのヘルスチェックでなく、どのリージョンからヘルスチェックを行うか選択できるようになった。
2. AWS Config Rulesが新しく4つのリージョンで利用可能になりました
AWS Configが東京リージョンを含む4リージョンに対応
- 以下は東京リージョンでテンプレートで提供されている「EBSの暗号化状態の確認」「CloudTrailがONか確認」「EIPがアタッチされているか確認」の3つのルールを有効化した様子。
- 現在のところ組み込みで7ルールが用意されている様子。
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のステータスが参照可能になった。
4. AWS LambdaでNode.js 4.3.2が利用可能になりました
- Node.js 4.3.2が利用可能になった。
- Node.js 0.10のEOLが2016年10月にくることを見据えるとプロダクションコードがあれば移行を検討する必要がある。
- 非同期処理にPromiseが利用可能になっており、無料で読める「JavaScript Promiseの本」がオススメされている。
5. Pipeline スターターキットで、AWS 上での継続的デリバリーをお試し
- CloudFormationで構築する、GitHubからソースを取得してJenkinsでビルドして、まずBetaサイトのEC2インスタンスに、次に本番用EC2インスタンスにデプロイするCodePipelineを構築するサンプルキット。
http://aws.typepad.com/sajp/2016/04/explore-continuous-delivery-in-aws-with-the-pipeline-starter-kit.htmlaws.typepad.com
6. AWS Black Belt Online Seminar 「Lumberyard」資料公開
- LumberyardとGameLiftの日本語資料が結構少ないなか、まとまったものとして貴重な資料
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のコンソールで信頼関係の構築が簡単にできるように
- AWS Directory ServiceのコンソールでAWS Directory Service for Microsoft Active Directory (Enterprise Edition)とオンプレミスのADなどとの間の信頼関係の構築が簡単にできるようになった。
- ドメイン名、パスワード、方向(Directory Service→オンプレ、オンプレ→Directory Service、両方向)、フォワーダーのIPアドレスを指定して構築
- ソース:https://blogs.aws.amazon.com/security/post/Tx1GPXG33HSTQCE/Now-Available-Simplified-Configuration-of-Trust-Relationships-in-the-AWS-Directo
- ソース:Announcing Simplified Trust Configuration for 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の学習モデルをシャッフルするように改良
- 作成したモデルの品質向上のために、投入するトレーニングデータをデフォルトでランダムにシャッフルされてから投入されるように改良した。
- ソース:Now improve your machine learning model quality with data shuffling in Amazon Machine Learning
AWS関連
11. AWSアカウントとVPC、分ける? 分けない?: 分割パターンのメリット・デメリット
- 運用上、環境によりアカウントを分けることが多いが、その方式ごとのメリデメ比較
その他
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の固定化ができると思いますが試してないので誰かお願いしますって感じです。
ということで今週は以上です。