セクションナイン の 吉田真吾（@yoshidashingo）です。
AWS公式
Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました
- General query log(発行されたSQLやクライアントの接続時間など)、Error log、スロークエリ、AuditログをCloudWatch Logsのロググループに自動的に収集することができる。
- 収集したログはS3にエクスポートしたり、LambdaやElasticsearch Serviceにサブスクライブさせて後続の処理(ESへの取り込みやLambdaで何かの処理を実装)することが可能
たとえば、定期的に監視サーバーから上記のログをさらってESに入れたり、エラー行を見つけたらアラートを送信していたような処理は管理系サーバーなしにリアクティブな仕組みで可視化することが可能になる。
AWS Auto Scaling
今までAuto Scaling可能だった複数の機能がひとつのダッシュボードで管理可能になった。
LambdaがGo言語とC#(.NET Core 2.0)をサポート追加
AWS Lambda での C# (.NET Core 2.0) サポート開始
AWS FinTech リファレンス・アーキテクチャー日本版の公開について
日本の金融機関やFinTech業者がAWSを利用する際によく参照する要求事項を整理し、CloudFormationテンプレートにして公開した。
特集ページ：FINTECH - アマゾン ウェブ サービス (AWS)
SageMakerのアップデート
- モデルのトレーニングと推論処理のホスティングに利用するストレージをKMSで暗号化可能に。
- Word2Vecの最速実装であるBlazingTextを複数のCPUやGPUで並列化して処理する。すぐに試せるノートブックのサンプルはこちら
- アクティビティをCloudTrailで記録可能になった。
Gunosyさんの記事配信をKinesisで最適化した話
AWSもブロックチェーンやってるってよ
- ブロックチェーンパートナーのソリューションを利用してAWS上でブロックチェーンのシステムを作りましょうという話
AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード
- ストリームデータをAurora PostgreSQLにETLするパイプラインの作成方法
- 間でLambdaでファイル形式の変換やデータ形式の変換をしながらロードすることでリアクティブで自動化されたパイプラインができる
機械学習と BI サービスを使用してソーシャルメディアダッシュボードを構築する
- Firehoseに受け取るTwitterのストリームデータをLambdaに発火してAmazon TranslateとAmazon Comprehendで自然言語解析処理して書き戻したS3上のデータに対して、QuickSightからAthenaでクエリさせることでダッシュボードに表現する
- Amazon Translate/Comprehendを用いることで、地域ごとに言語が違うことを吸収して分析と地図などへのプロットができる。
Microsoft Excel を使った Amazon Lex チャットボットの構築
- AWS コミュニティヒーローである Cyrus Wong (香港専業教育学院のデータサイエンティスト)と学生4人による成果発表。
- Excelに必要事項を埋めてアップロードするとAmazon Lexを使ったチャットボットが構築できるという実践例
- ExcelをS3にアップロードし、発火したLambdaでExcelを分析してSAMテンプレに置き換えて、デプロイする。
"ベンダーロックイン"という都市伝説をぶっ倒せ
クラウド業界にはいくつかの金科玉条のような都市伝説があります。一般的には「クラウドよりオンプレのほうが安全だ」「クラウドは信頼性が低い」そして、「ベンダーロックインされる」といったあたりです。
いまやあらゆる仮想ホスト基盤のパッチが素早くオンラインで適用されていき、セキュリティ基準やガバナンスレポートも網羅しており、仮想ホスト基盤より下の安全性については完全にクラウドの勝利です。信頼性についてはアーキテクチャで担保するのが当たり前になりましたし、そもそもクラウド上のサーバー運用保守をやっていると毎年のように仮想サーバーが単体でわけのわからないダンマリ状態に陥ったり、ノイジーネイバーの影響を受けるようなことが皆無になってきました。
そしてベンダーロックインについても、「組織の意思決定の遅さや成熟度が低いことによる」ロックイン以外は存在しないということがすでに明らかです。ということでくだんの記事。
- 長期契約が必要ない：利用分のみに課金されるように設計されており、好きなテクノロジーを持ち込み、必要なくなればVMをエクスポートしたりして別に移ることも容易に可能である。
- 顧客が技術選択可能：プロプライエタリなツールを代替する業界標準なソリューションをサービスとして多数展開しているので、アプリケーションをそういった業界標準で可汎性の高いソリューションに合わせて移植することができる。
- 乗りやすい、出て行きやすい：移入／移出いずれについてもサポートするツールやドキュメントが用意されている。たとえばSQL、LinuxやXenといったオープンスタンダードな技術でできているので、クラウド間やクラウドとデータセンター間のサーバーやデータの移動がしやすくなっている。
アプリケーションの移植には基盤の移行より何倍ものコストがかかるため、どこにアプリケーションを配備していても移行に想定以上にコストがかかるというのはよくある話であること。また、自社で数十万VMや数PBレベルのストレージを運営している場合であれば専門組織を抱えてより高いコスト効果を目指すというのも当然アリだが、それはすべてAWSに移行してしまうというよりそもそも何倍も大変であるという点には留意したいですね。
その他
Amazon Web Services 業務システム設計・移行ガイド 一番大切な知識と技術が身につく
出版されたそうです。AWSで業務システムを設計・構築する方は買って読みましょう。
- メディア:
- この商品を含むブログを見る