Developers.IO 2017に参加してきました
今年も開催された、Developers.IO 2017に参加してきましたので、ざっくり感想をまとめました。
午前はあいにくの雨で、しかも傘を会社に置き忘れてもっていなかったのですが、会場はいつものSAPジャパンさんで行われ、半蔵門駅に直結していたため、ほぼ濡れること無く、会場入り出来ました。マジ感謝ですｗ
パンフレットやステッカー等
今年はクラスメソッドテクニカルライブラリーという、実際にAWS移行に役立つテキストが入っており、とても太っ腹だなと思いました。
あと、おみくじガチャなるものがあったので、やってみた結果、大凶でした。。。w
参加したセッション
今年、参加させて頂いたセッションは以下の通りで、これらを中心にまとめました。
- 【C-1】 クラウドネイティブなRDBMS Aurora
- 【C-2】 AWSで始めるビッグデータ分析
- 【A-3】 開発環境でのDocker活用事例と本番運用に向けて考えたこと
- 【A-4】 Amazon Elasticsearch Service の使いドコロ
Colud Native RDBMS Aurora
Auroraの特徴
- 管理が簡単
- 高いスケーラビリティ
- 高可用性と耐久性
- MySQL 5.6, PostgreSQL 9.6
- 高い安全性
- 安全マネージメント型
- 高スループット
- 1つ１つのクエリが大きい場合はパフォーマンスがいい場合も
- バッチは合わない場合も
機能
Storage
- 論理的な共有ストレージボリューム
- 2重障害でも書き込み可
- 3重障害でも読み込みは可
Quorum -> 多数決
Log Structured Storage
- データをログのように先頭から追記する
- レコードはsequence numberを持つ
レプリケーション
- メタデータを渡す
- 間にCacheを介している
- Cacheを独立させている
フェイルオーバー
- SlaveがMasterに昇格
- 昇格したタイミングで全Cacheをパージする
- そのため、1~2秒オフラインになるので、要注意
Lambda to Aurora
- 実装はストアドプロシージャ(非同期)
- トリガーやイベントスケジューラと組み合わせ可
IAM
- AuroraにIAM権限でログインできる
- スループットが低い
Database Cloning
- 即座にDBデータを複製
- クローン先で変更したときにコピー
- 削除してもデータが増える
Database backtrack(まだ未搭載)
- DBデータを任意の時点に高速に巻き戻す
高速フェイルオーバー
- MariaDB Connector/Jを使用すると各ノードのステータスを判断してWriterへ接続出来る
所感
最初はAuroraについて、名前程度しか、知見が無かったので、RDSとは別に有るものかと思ってましたが、Amazon サービス内のDBエンジンという位置づけらしく、MySQL、PostgreSQLとの互換があるとのことで、RDSでMySQLやPostgreSQLという選択肢から、RDS でAuroraという選択肢もケースバイケースで有りかなと思いました。
AWSで始めるビッグデータ分析
- データ分析をパイプラインで考える
収集、前処理、保存、分析、可視化
- 各サービスが何に最適化されているか、最適化された結果のトレード・オフは何か
- パイプライン上のそれぞれのジョブに最適なサービスを選択する
収集
データタイプに着目
集めたデータはS3に集約
前処理
- バッチ -> EMR, EC2
- リアルタイム -> Lambda, Kinasis Analytics
分析
可視化
Redshiftパフォーマンスチューニング
テーブル設計が重要
- 分散キー
- ソートキー
- 圧縮タイプ
Redshift Spectrum
- S3上のファイルに直接クエリ操作可能
- クエリ単位の課金
- データロード不要
EMR
Athena
- マネージドPresto
- サーバレス
- S3王のファイルにクエリ操作可能
Kinesis Streams
- 24h ~ 7day
- 遅延は1秒未満
- Autoスケールは出来ない
Kinesis Firehouse
- 収集と配信
- S3, Redshift, ElasticSearch Serviceにデータを配信できる
- Autoスケール可
- ストリームデータに対してLambdaで実行可能
Kinesis Analytics
- ストリームデータに対してSQL操作可能
- Autoスケール可
QuickSight
- BIサービス
- AWS内外のデータソースにアクセス可能
所感
実は丁度、進行中の案件でSparkを中心とした分析基盤の構築を進めているところで、AWS内で構築するならと言う前提で設計をしていたので、自分のイメージに近い構成で紹介されている部分が多かったので、だいぶ自信につながり、安心して実装を進めていけそうなイメージが掴めました。
Docker活用事例
- 開発環境のミドルウェア
- アプリケーションのモックサーバ等
開発環境で使うメリット
- リソース消費が少ない
- 再作成が用意
- ポータビリティが高い
- エコシステムを利用できる
OfficialとPublic
- Officialのものは、直接イメージ名でpull出来るもの(通常はusername/image-name)
docker-compose
- 複数のコンテナをまとめて管理
- 複数のコンテナのネットワーク管理
AWS本番環境でDocker
メリット
- サーバ設定はDockerfileに集約
- 役割が明確
- ビルドやデプロイが早い
安心してデプロイ出来る
Docker Swarm
- kubernets
- ECS
ECS
- AWSとの親和性高い
クラスタ設計
- リミット
- CPUリミット 予約するCPU割り当ての最小数
- ハードメモリ制限(指定が必須)
- ソフトメモリ制限
- スケーリングとインスタンスタイプ
- Auto-Scalingに設定できるインスタンスは1つ
- アプリケーションの特性ごとにクラスタを分割する
- コンテナ配置戦略
デプロイ
- デプロイフロー
- デプロイ戦略
ローリングアップデート
ダウンタイム0でdeploy出来る
ロギング
- クラスタインスタンスのログ
- CloudWatch Logsに出力できる
- コンテナのログ
- awslogs logging driver(STDOUT -> CloudWatch)
- fluentd logging driver(fluentd -> S3, Logentrie)
モニタリング
- アプリケーション
- ログ監視
- パフォーマンス監視
- コンテナ
- リソース監視
- ディスク監視
所感
Docker中心の話が半分、ECS中心の話が半分といった割合だったため、個人的にはECSをもう少し掘り下げた内容だったら満足したかなと。
Amazon Elatic Search Service
https://speakerdeck.com/shinjifujimoto/amazon-elasticsearch-service-falseshi-idokoro
- 適合率 -> 適切なドキュメントが多いと高い
検索システムにおいてソートは重要
- フリーワード検索ではマッチ度でソート
プライマリーシャードの数は変更できない
Analyzer
- Cahactor Filter : 検索に不要な文字列は取り除いてくれたり出来る
- Tokenizer : 単語他院位で分かち分け
- Token Filter : 品詞のつなぎ部分?(はとかのとか)を除去してくれる
AWS上での選択肢
- Amazon CloudSearch (Solr)
- 機能の制限有り
- EC2上に構築
- Amazon ElasticSearch Service
- Elastic Cloud
- Elastic Cloud Enterprice
所感
こちらに関しても、丁度ElasticSearch絡みの案件を進めていたところで、今まで駆け足でElasticSearchをやっていた部分が多かったので、知見の再確認がとれて、参考になりました。
全体を通しての感想
AWSのシェア率と平行して、参加人数も徐々に増えていっている感じがあり、まあAWSに限らずGoogle CloudでもAzureでもいいけど、どれかのPaaSに特化したスキルを持っている事は、今後のエンジニアのキャリアパスに有利に働くということを確信しました。
その他のセッション内容については、公式ブログで随時、更新されていくと思います。
