JAWS DAYS 2015 に参加したときのメモ

デベロッパーの方に送る、AWSクラウドを支えるアーキテクチャと技術

AWSの中身を支えるアーキテクチャについて

AWSが提供しているサービスはそれだけでは顧客に提供できない
つまりビルディングブロック
それらをうまく使ってもらってイノベーションを

AWSを支えるアーキテクチャ

AZ間通信は1,2ms
大きいところで5つくらいのデータセンターで1つのAZを構成している
AZのDC間では1/4msくらい
AZ間でのフェイルオーバーを意識する

単一DCでは50000~80000台くらいのサーバ
単一DCで最大102Tbpsのトラフィック
カスタムのNW機器を利用
SR-IOVを利用

機能

Larger EBS(16T・20,000IOPS)
よりシンプルに使いやすく
復旧などがしやすくなった

EC2 Enhanced Network
レイテンシのばらつきを改善した
同じものを借りているので、同じスペックに近づける

Amazon Cognito
・認証情報の取り扱い
・デバイス間の同期
・プッシュ通知
といったサーバ側でない環境も整えていく

2lemetryの買収によってIoTが今後どうなっていくか注目

AWSを支える技術(プログラマ寄り)

非同期API
　多くのユーザからのリクエストを効率よく処理したい
　サーバ側の利点として、スケーラブルかつ高可用なバックエンド
　EC2での非同期API – RunInstances → DescrieInstances(状態問い合わせ)

リトライとバックオフ
　巨大システムではリトライが欠かせない
　エクスポネンシャルバックオフ→リトライ実行までの時間を伸ばす(5秒後にダメなら10秒後にリトライ)
　
べき等性
　ある処理を何度やっても同じ結果が返却される
　これがないと2重課金などが発生する

一貫性
　AWSでは一貫性と強一貫性とを使い分ける
　

Cognito + SNS + zabbixでサーバー監視業務アプリを作ってみた

Amazon Cognito

モバイルサービス(2014.7-)
Sync　クラウド上にモバイルと同期できるデータストアを提供、key-value型
conflict時はデフォルトで最終更新時間をみる
Identity Broker モバイルからAWS上のリソースへのアクセス認証と制御

Amazon SNS

メッセージの配布サービス
マルチプロトコル対応
　プッシュ・メール・キューイングシステム・異なるプラットフォームの差異を意識できずにプッシュ通知可能

実装

北海道　農業　クラウド

SKYARC(スカイアーク)
日本の畜産は危機的状況
Farmnoteという会社を立ち上げた
牛群管理スマートフォンアプリ

日本の牛400万頭 → 生産供給が不安定に
牛を大切に育てること → 人の利益につながる
タップするだけで経営を見える化する
アンバサダーとして　農家と一緒に環境づくり
センサー　　　　すべての牛をインターネットに、牛のウェアブルデバイスにより牛の状態をインターネットに
グローバル展開　世界の生乳生産量はあがっている、牛群管理システム市場もあがる
運用については少人数なのでサーバを持たない方針
TypeScriptで作成した静的ファイルをS3で配布している

特徴的な利用方法

GitHub
　営業には顧客要望をIssueとしてあげてもらう
　ドキュメントはWikiに集約
　通知が弱いため、slackと連携させている

ZenHub GitHubを使いやすくするChromeの拡張機能
　Issueがカンバン表示されて進捗が見やすくなる

circleci Jenkinsサーバを持ちたくない
　GitHubと相性がよい、これを利用してデプロイを自動化できる

papertrail ログ管理サービス(ログサーバ)
　導入が容易 terminate時にログがなくなるため、保持する仕組み
　ログのグルーピング、検索やフィルタリングが強力

Site Care FREE – SSL認証監視・HTTP死活監視など

地方のベンチャーにとってクラウドを乗りこなすのは必須条件
そして、乗りこなせれば場所を意識しなくなる
AWSにないものも他で借りる、するとしばらくするとAWSででてくる
運用や保守に振り回されず、自分たちのサービスに集中できる環境を作る

加工品が目の前にある状態では、農業が見えてこない
インターネットだからこそ、人と人とがつながるサービスを
東京の机の上で、農業のシステムを作ることはできない

人と人との距離、顧客との距離
使ってもらっているシステムでは最高のシステムはできないのではないか？

感想として、すごく良かった

東急ハンズのクラウドデザインパターン

フルクラウドに向けて
2012年からサーバを購入していない

why AWS?
　サイジングしなくてよい、容量のこと気にする必要なし
　AWSがガートナーにも書いている通りクラウドNo1だから

以下の問題点解決のためにクラウドに
・リアルタイム
・夜間バッチの停止
・スケールアウト

POSレジからFTPを利用して
S3バケットのイベント認識機能でSQSにキューを入れる
S3にファイルを置くだけで後続処理がなされる

スケールアウトの懸案-AWS側にもボトルネックが

Infra寄りのDevがお送りする「RDS for Aurora」徹底検証

mysql 5.6 互換の早くて安くて安全なRDB
・早い → 最大5倍のパフォーマンス
・ストレージエンジンはInnoDB(インポート時に強制変換)
・ストレージサイズは10GB-64TBまで自動拡張
・レプリカの作り方が容易
・スケールアウトはレプリカを増やすのみ(マスターは増やせない)
・レプリカが自動的に親に昇格する(早くて60秒、遅くとも120秒らしい)
・過去データ全体がそのままの状態で取り出せる、つまり差分適用がないため高速
・同じデータを見ているため、レプリカ側で書き込み遅延などがない
　そのためレプリカがレプリカのために力を発揮できる
・書き込みはノードとしてはひとつだが、裏のストレージがスケールするためある程度期待できる
・障害シミュレートが容易になった(独自SQLコマンドで障害を発生させることが可能)
・Cache WarmingはInnoDB Buffer dumpを利用している？？