2017年3月11日参加的JAWS DAYS 2017会议笔记

8 月 ago

逸, 科

4 minutes

红颅骨呈现《如果在AWS上进行应用开发，需要了解的事项》

架构最佳实践

単一障害点をなくす、すべてが失敗し得るという前提で考える

最初に１ホストを複数に分割する⇒Webとデータベース（RDS）
複数のWebインスタンスを異なるAZで
RDSはMulti-AZ
ELBを利用して負荷分散

Build Security Every Layer

通信経路および保存されたデータの暗号化、IAM／セキュリティグループ

Leverage Many Storage Options

万能なデータストアは存在しない、特性に応じて使い分ける
Storage

Object Storage: S3, Glacier
File/Block Storage: EFS(NFS、共有ディスク), EBS

Database

NoSQL: ElastiCache, DynamoDB
SQL: RDS（トランザクション処理）, Redshift（DWH）

例

静的コンテンツはS3に
セッションやステートはDynamoDB
DBのキャッシュはElastiCache

Implement Elasticity

IPアドレスで参照しない（名前ベースで）、分散させる

Think Prallel

EMRを用いて並列のMapReduceジョブを実行、ELB、１つのKinesis Streamと複数のKCLアプリケーション、バックエンドとしてのLambda
1インスタンスでN時間 = N台を1時間 ⇒ コストは同じ

Loose Coupling

コンポーネント間の結合度が緩やかになるほど、スケーラビリティは高まる
すべてのコンポーネントはブラックボックスとしてデザイン（APIアクセス、DNS名でアクセスなど）
Queueを使って疎結合に（部分的なretryがしやすくなる、重たい処理だけをスケールする）
Service Discovery

各サービスで増えたリソース、減ったリソースに対して透過的にアクセス
Auto Scalingを使ったELB自動登録、Consulなど

Asynchronous Integration

同期処理である必要がなければ非同期にする（その処理、本当にレスポンス必要ですか？）
アプリケーションがブロックされない
スケーラビリティ＆高可用性
Frontendを停止することになくBackendを容易にメンテナンス可能
リクエストの処理順序やリトライ等の制御が容易に（一方、数珠つなぎで全体の見通しは悪くなる）

Don’t Fear Constraints

より多くのメモリが必要？⇒負荷分散、キャッシュ
データベースのIOPSが必要？⇒リードレプリカ、シャーディング、データベースのキャッシング
問題のあるインスタンスを破棄し、置き換える

十二因素应用

デプロイされているアプリとコードベースは常に1:1であるべき

Dependencies

依存関係を明示的に宣言し分離する
特定の環境に暗黙的にインストールされているパッケージやツールに依存せず、アプリに同梱する
例：gemとbundler

Config

OSレベルの環境変数によって注入されるべき
設定ファイルは言語／フレームワークの環境依存になる

Backing Service

ネットワーク越しに使うものはすべてリソースとして扱い（URLのように）、データベースはアタッチされたリソースとして扱う
リソースの切替はリソースハンドルの切替（URLの切替）とする

Build

build、リリース、実行の３つのステージを厳密に分離する
すべてのリリースは一意のIDを持つべき（どの環境にどのIDがdeployされているか）

Process

アプリケーションをStatelessなプロセスの組み合わせとして実行！
スケールアウトの単位としてプロセスモデルは分かりやすい（スレッドはメモリ共有するなどで管理が複雑）
永続化する必要のあるデータ（次のリクエストでも利用するデータ）はDBなどstatefullな外部サービスを利用
ローカルディスクのファイル、メモリ上のデータはあくまでもキャッシュとして扱う

Dsiposability

グレースフルシャットダウン

Dev/prod parity

開発・ステージング・本番環境をできるだけ一致させ、CI/CDの効果を発揮する

Log

出力ストリームの保存先やルーティングにアプリは関与しない（標準出力に吐き出すだけにする）
収集、保存、インデックス化し分析する環境をアプリの外に用意する

Stateless

ステートフルにになる要素を水平スケールするリソースの外部に配置
Session情報(スケールアウトすると新しいインスタンスから見えない）⇒DynamoDBに見にいってローカルにキャッシュ

DevOps 运维开发

自動化と構成管理：プロビジョニング、設定、オーケストレーション、レポーティング
ApplicationとInfrastructureをいずれも、バージョン管理し、build&testし、成果物を登録し、デプロイする
繰り返し継続的に行う

Tool

AWS上的DevOps工具

各言語のSDKが用意されている（IDE向けのプラグインも用意されている）

Cloud formation
Jenkinsを使ったデプロイ

最佳实践

ダッシュボードで通常時と異常時を把握する

AWS安全性之死 \m/ —— 安全之鲨鱼様的启示 ~ by 安全-JAWS

网络

public subnet: インターネットに直接接続可能なサブネット（公開サーバを置く、EIPとの紐づけもできる）
private subnet: NATゲートウェイを経由して内⇒外のインターネット通信は可能

statefull / stateless

NAT配下のクライアントのSource Portはハイポート（1024-65535）からランダムに設定される
Statefull: 戻りの通信もよろしくしてくれる
Stateless：内⇒外も書かないといけない（1024-65535/tcp）
Security GroupはStatefull⇔Network ACL（subnet単位で通信を制御）はStateless

VPN

ユースケース

Webサーバ／DBサーバのメンテナンスはプライベートネットワーク経由で行いたい（平文でインターネットを通さない）
社内システムで事業所とAWSの間(Direct Connectは品質を高めることもできる)
AWSを既存システムの拡張リソースとして使用するような場合（繁忙期など）

VPNの場合、AWS側には２つのVPNエンドポイントが用意される（Customer Gateway側で２つのトンネルを張る必要がある）

static routingもしくは、BGPによるダイナミックルーティング（対応機種のFAQ参照）

Direct Connect（専用線接続）

宅内～接続ポイント⇒一般的には通信キャリア
接続ポイント～AWS⇒AWSが提供
VLAN分けをできるキャリアと、できないサービスがある
TOKAIコミュニケーションズ、Colt(旧KVH)

网络应用防火墙（WAF）和分布式拒绝服务（DDoS）

L3/L4：Infrastructure
L7: Application

AWS Shield

CloudFrontを使って、Shieldオプションを有効化
Shieldの後ろはAWSでも、オンプレでも対策可能
防御対象：CloudFront, ELB, ALB, Route53
監視：常にモニタリングしてベースラインの作成、異常検出
Basicは無料で利用可能、AdvancedはDRT付き
Billing Protection
DRT：WAFのチューニングやルール作成もやる
CloudFrontさえ入っているなら、導入しておかない手はない！

WAF (网站应用防护)

PCI-DSS 6.6にもWAF導入について明記されている

AWS WAF

カスタムルール（IPアドレス制限／文字列制限）、SQLI/XSSといった基本的な対策が可能
構成：CloudFront, ELB, ALBに仕込めるマネージドWAF
ルールを正規表現で書けない、WAF検知ログは100件まで

AWS WAF / WAF on AWS / SaaS WAF / Cloud WAFの比較

SaaS WAF / Cloud WAF: 正常な通信の確認、DNSの向き先変更程度で導入できる
WAF on AWSはオートスケールに対応している製品が多い
AWS WAFはセキュリティ面では物足りない

「セキュリティ開発」はなぜ浸透しないのか

AWS 配置

可以通过简单的“可视化”来轻松地查看复杂的AWS资源。

構成情報のスナップショットの取得
変更内容を追うことができる、SNSを使った通知も可能
AWSリソース間の関係性の確認（EC2とVPC/Security Group/ALBとの関係）
EC2 Systems Manager: エージェントを入れると、OSの中の情報を取れる、コンソールからコマンドを発行⇒OS上の変更管理が可能になった
IAMの構成管理

ユースケース

AWSリソースの一覧でAWSリソースを確認できる、削除されたリソースについても追跡可能
いつ、どのように変更されたかを記録するので証跡として利用可能
関連するAWSリソースも辿れるのでトラブルシュートしやすい

AWS Confing Rules

AWS Configで記録した設定が正しいかを判定するルールを定義できる
例

セキュリティグループがフルオープン
MFA設定していない
ACMの証明書の有効期限があと少し

マネージドルール

Instanceにtagをつけているか？（billingのために、作った人／プロジェクト名をつける）
SecurityGroupがフルオープンになっているか？

カスタムルール

判定機構はLambdaで実装⇒極論、修正することもできる
awslabsにカスタムルールが公開されている（現在34）

AWS Configを有効化して可視化

Auto Scalliingで、頻繁にインスタンスの起動／削除をしていなければ、課金額は大きくない

具备亚马逊Lex功能的聊天机器人

Alexaと同じ技術で提供されている
音声認識＋自然言語処理

コンポーネント

ユーザ入力⇒出力
Intents：意図（Utterance/Slots）
Fulfillment：処理

Utterance

Intent（例：RegisteruserForEvent）に対してユーザ入力を紐づける
Sample utteranceを複数事前に定義する
反復して学習することによってユーザ入力の言い回しの揺れを吸収（徐々に改善していく）

Slot

SLOT NAME: eventDate, SLOT TYPE: AMAZON.DATE
12 March 2017 / tomorrowみたいな揺れを吸収できる

Fulfilment

AWS Lambdaとの統合⇒クライアントにレスポンスを返す

複数のintentをflowにすることで、より自然な対話が可能になる

もう少し知りたいですか？ ⇒ yes ⇒ 次のintentに繋げる
曖昧な答えの場合は、プロンプトを出す（「”yes”か”no”で答えてください」）

Lambdaとの統合

Lexがユーザ入力をparseし、intent/slotsを渡してlambdaを起動、lambdaからレスポンスを返す
dialogAction：会話の流れをつかさどる（例：ConfirmIntent）
facebookの場合、Response cardを返すこともできる（ユーザに選択肢リストを提示）

Lambda Functionの実装例

switchでintentごとの処理を定義して、1 functionで複数intentを処理
LexResponseBuilderでレスポンスをbuild

English Onlyでlaunchするが、複数言語をサポートするロードマップ

開発者からAWS Japanへプレッシャーを！

最初はよくテストして、エラーが多いようであればintentを細かく設定するなどの工夫が必要

无服务器的现在与未来

无服务器

サーバが要らないということではなく、開発者はサーバについて「考えなくてもよくなる」
2014年末のre:InventにてLambdaの発表
最大の特徴は、課金は使った分だけ（メモリ×時間×実行回数）

Function as a Service

アーキテクチャにおける責務

Stateful >> Stateless
永続データ >> 揮発性
バッチ >> イベントドリブン

Lambda goes everywhere

コンテナベースの実行環境はportabilityが高いので、いろいろなところにデプロイできる
Athenaの基盤もLambda
Greengrass(AWS IoT)
CloudFrontのEdgeの上

代表性较高的无服务器架构

認証ロジックをBaaS、DynamoDBにクライアントから直接アクセス、SPA＋API Gateway

メッセージドリブンアプリケーション

オンライン広告システム
コンテンツのサムネイル作成（image magicを載せたlambda）
ログのストリームプロセッシング（kinesis/kafkaから取って、加工して、S3やDynamoに入れる）

生态系统

アプリケーション開発者のノウハウ発信が足りない
cloud packの毎日放送事例

Serverless framework, Apex, Lamvery, Swagger, AWS Serverless Application Model(SAM), Postman…
SAM

CloudFormationテンプレートで管理できる
lambda, API Gateway, DynamoDBがサポートされている
app-spec.yaml -> CloudFormation（codeはS3経由でデプロイされる）

由于无服务器架构，可以做些事情。

TypeScriptしか書かず、あとは外部のサービスを使っている
firebase（auth）, Netlify（static site hosting）, Cloudinary（画像管理）, Algolia（検索）

Serverless, NoOpes and the Tooth Fairy

来るサーバーレスな未来では、アプリケーション開発者が運用に責任を持つ
プロバイダの技術情報や、内部技術が何に依存しているか理解する
可視性が下がる、自分自身で問題をfixできないし新機能を実装することもできない
売れていないサービスはシャットダウンされるかも

日経新聞事例（紙面ビューアー）

最大18,000回/1分間のinvocation

システムをリアクティブに設計する

イベントの発火やwebhookなどに対応している周辺のマネージドサービスとうまくつないでいる
シンプルなマイクロサービスとして
一度トライアルしておき、いざ活用する前にはまりどころなど判断

SPA的开发流程

ビューの作成
テスト駆動でアプリコードを追加（テストがないと、統合時に問題が起こったときの切り分けが困難）
例：jQuery+Jasmine
ローカルで開発可能、チーム開発がはじまったらS3で
テスト時のブラウザキャッシュに注意（chromeの開発者ツールでdisable cacheするとか）
AWSに繋ぐ前に、１行書いたら１行テスト

Cognitoを使った認証+フェデレーション

例：Google+
Googleで認証してIDが払い出される
ブラウザがCognitoにJSでアクセス、CognitoがGoogleに検証、OKであればDynamoDB書き込み権限を払い出す

DynamoDBを使ったデータの管理
Lambdaでシステム強化

DynamoDB直接読み書きでは仕組みとしてできてしまう、「不正なクエリからの保護」（lambdaでvalidationするなど）
「ユーザ全員分の集計」などの情報提供のため

Serverless Single Page Apps

Ben Rady著、Step by Stepガイド（日本語版が間もなく出る予定）

仅提供一种中文翻译：

参考（在某些地方被提及的其他报告）

サーバーレスでシステムを開発する時に⼤切な事 from Hiroyuki Hiki

[亚马逊云工作坊] 体验一下Amazon Kinesis Analytics

http://qiita.com/takada_tf/items/f03c36eed9e22eb74744

动力学

処理した結果を複数システムに送る必要がある

kafka or Kinesis Streams

しかも機械学習を行なう

Spark Streaming or Storm

Kinesis

Streams

マネージドkafkaのイメージ：入出力に制限はある（入力：秒間1MBまたは1,000put）

Firehose：S3, Redshiftへ簡単に配信
Analytics：SQLクエリー

Stream Source/Destination（StreamかFirehose）

入力側を決定する（Strems or firehouse）
入力データの型定義をおこなう
SQL分を作成、デプロイ
出力先を決定する（Strems or firehouse）

kinesis demo stremasは良く停止するので注意・・・

データ定義は大文字で定義（もしくはselect句をダブルクォーテーションで挟む）

窗户的概念

FLOOR((“SOURCE_SQL_STREAM_001”.ROWTIME – TIMESTAMP ‘1970-01-01 00:00:00’) SECOND / 10 TO SECOND)
10 TO SECOND⇒10秒間隔

Sliding Window（データが流れてきたら出力を開始する）

Time(60sec：レコード受信をトリガーに直近60sec分を集計)
Row(2rows：自分+直近2レコード)
１つのdestinationに対して、TimeとRowを両方設定できる

添加参考数据

現状、Reference Dataを追加すると動作しない（サポート確認中）

概括

Analyticsは簡単な集計処理ならよいが、複雑な処理はSpark Streaming等を利用したほうがよい

【Alexa之旅】尝试玩转Alexa技能工具包【基础篇】

https://github.com/sparkgene/jawsdays-ask-handson-beginners/wiki