AWS Casual Talks #2 に参加してきた #awscasual
我々が普段使う『Casual(カジュアル)』という単語、意味合い的には上記抜粋したようなイメージが強いでしょうか。今回参加した『AWS Casual Talks #2』にもその単語が入っているので、何の気無しにイベントページを見た方は『おっ、気軽に語れる/聞ける会なのかな』と思うかも知れません。そして最近時々この『casual』という単語が入ったイベントも開催されていたりします。実際に中身は"カジュアル"なのでしょうか？
答えは否。きっと言葉の意味とは正反対なはず。今回のこのイベント及び『AWS Casual Talks』シリーズの主催者であるcon_mame(TwitterID:@con_mame)さんによるイベント主旨を一発で解説した画像がありますので説明として替えさせて頂こうと思います。
AWS Casual Talks#1 で説明したカジュアルとはを再掲 http://t.co/CdlqWIlDES #awscasual
— con_mame (@con_mame) 2014, 4月 18
開催場所はアマゾン目黒オフィス アルコタワー。AWSの本丸です。暫く前まではアネックスでしたが最近こちらのビルにお引っ越しとなりました。
開催会場となるフロアも御覧の通り、広々且つ座席も座りやすい一風変わった？テーブル付きの椅子でした。会場自体は横に広い感じ。
前回は個人的にはイベント告知に気付いた時は定員瞬殺、今回第2回は告知直後にイベントの存在に気づき、辛うじて参加登録に間に合う事が出来ました。(実際は告知15分程で定員が埋まるという人気振り！) そんな注目度の高い『ガチ』トークが聞ける今回のイベントについて参加メモをまとめてみましたので御覧ください。
目次
メインセッション
CloudTrailでログとれ〜る
- 発表・登壇：カルビ生焼け王(TwitterID:@kani_b)さん
発表資料
講演メモ
- 自己紹介：
- クックパッド社から参戦。@con_mameさんがメンターを担当されているらしい。
- 別名(カルビ生焼け王)は、カルビを食べようとした時に生焼してしまうことから付いた模様。
- ここ1週間のマイブーム＝秘密鍵の交換と証明書失効(一同溜息と冷笑)w
- 本日のお題：
- ギャグみたいなタイトルでスミマセンw
- で、お題の前に一つ。色々思うことがありまして…例のHeartbleedの件。
- Heartbleed Bug
- ハートブリード - Wikipedia
- 巷を賑わすHeartbleedの脆弱性とは？！ — Mobage Developers Blog
- OpenSSLの脆弱性で想定されるリスク - めもおきば
- 問題発覚後、AWSはマッハで対応。直接リモートで攻撃を受ける場所は全て潰されたので心配は無い。EC2上のインスタンスは自分でOpenSSLをアップデートする必要あり。
- SSLを使っている全サービスでは、新規作成した秘密鍵から証明書を再度作成して入れ替える必要がある。
- また、元々使っていた証明書も失効(revoke)させる必要あり(成りすませる可能性があるので)。ここは忘れがちだけど確実に対応。CipherSuiteも見直す必要あり。
- 本題へ。
- AWSをお使いの皆様であれば思い悩む事…『ログが欲しい』。
- 過去AWSサービスではログは残っていなかった。監査ログ、バージョニング、トラブルシューティング…この辺り、どうロギングしたものか。
- 何が要因となってトラブルが発生したのか、突き止める為の情報は要望としても大きかった。
- ログ取得の案としては、HTTPのプロキシを挟んでログを取り中身をパースするなど考えられるが、この場合Proxyが落ちるとアウト。APIコールがProxyに依存してしまう。また、HTTPの生ログをパースしたく無い等の理由も。
- 時は流れて...2013年11月、『re:Invent』米国で開催。参加して来ました。
- その時の様子。
-
「これは肉ですね」 #awscasual
— Kenta Suzuki (@suzu_v) 2014, 4月 18
- キーノートにて、CloudTrailのリリースが発表。歓喜する氏。一方それほどでも無い氏の周囲(あれ？w)
- CloudTrailとは
- AWSアカウント内での操作ログをS3に出力してくれる。出力をSNSで通知する事も可能。ログを他アカウントのバケットにも出力可能。
- ログ形式はJSON。ログ情報も色々入っていてお得！
- 実利用：基本、ログを勝手にパースしてよしなに扱う：AWSでは特に何も提供されていない。MongoやElastic Searchに突っ込むのもあり。SumoLogic、Splunk、Stackdriver、loggly等などのログ解析サービスを使うのもあり。
- AWS側で欲しい情報殆ど入りでログが取れるのは嬉しい。HTTP Proxyのようなクライアント縛りも無くなるし、失敗の記録も取る事が出来る。(※この点は監査的には重要ポイント)
- その時の様子。
- CloudTrailのつらい点
- まだあまり対応サービスが無い…現在8サービスが対応(EC2/EBS/Redshift/RDS/VPC/CloudTrail/IAM/STS)
- まだ太平洋を超えられない…(※現状対応しているリージョンは米国東部(ヴァージニア北部：us-east-1)、米国西部(オレゴン：us-west-2)のみ。
- リージョンとは関係無いサービス(IAM/STS)であれば日本で使う事も可能。ログ設定で所定の内容を有効化する事で対応可能に。
- CloudTrail、もっと使いたい！出来れば実践的な場所で…
- 2014/03/14：GAME DAYに参加してきた。全4箇所同時開催。(東京/大阪/名古屋/仙台) ※GAME DAYに関する模様は以下リンクからどうぞ。
- 2014年度版のGAME DAY、東京vs東京以外の会場という構成となり、相手は他会場のチーム。
- 相手に渡すIAMアカウントはPowerUser。そしてリージョンは…us-east!、これは聞いた瞬間にアガった！(本人談)
- …とは言え、対象サービスは狭い。EC2/VPCが構築で使ったサービスとしては対象となったのみ。
- そして、PowerUserなので、実はCloudTrailを無効化出来てしまう…(´・ω・｀)
- ひとまず防御してみる。CloudTrailを切られるのは避けられないのでテンプレートは固定。
- 実運用の為の学び
- IAMユーザーからCloudTrail周りの権限は取り除く。これはPowerUser Templateからは抜いて欲しい。(要望)
- ログの保持方法をまとめる。ログ集約用のアカウントにまとめる方向で。S3 Versioning、MFA Deleteを使う(こっちの方がよりスマート？)
- 攻撃タイム終了後…CloudTrailを確認。生きてる！(勿論中途半端に止められてた可能性はある)
- 早速ログ解析。ログは粛々と取れており、3つのインスタンスがterminateされている事は判明した。
- SQS/SNSメインの攻撃、VPC周りの攻撃が拾えていなかった。『とれーる、あんまり取れてない…』w
- まとめ
- CloudTrailはAPIリクエストをまるっとロギング。
- 運用時のIAM権限とS3バケットの扱いには気をつけよう。
- 対応サービス増＆東京リージョン対応(太平洋超え未だならず)については、正座して待つべし。
この後、氏がCloudTrailのログをパースしてGitに登録を行うサービス『iwas』を作成したとのお知らせがあり、そのデモを行いました。
</
p>
Data Stream Processing and Analysis on AWS: Fluentd, Elasticsearch, DynamoDB, EMR and Amazon Kinesis
- 発表・登壇：Kenta Suzuki(TwitterID:@suzu_v)さん
発表資料
講演メモ
- 自己紹介：
- 『"AWS Casual Talks"という事で、表紙もちょっとカジュアルにしてみました』
- 仕事でログ分析基盤・分析タスクを現在は担当しています。
- Kinesis歴は3年。(注：キーボードの話)
- 今日はログ解析基盤のアーキテクチャとkinesisの検証をしている話をします。
- Kinesisの紹介
- 昨年re:inventで初お目見え。Twitterストリームを解析するというデモが行われた。
- 実際の構造はストリームを流し込み、それを受け取る基盤。
- 色々なデータソースを直接Kinesisのエンドポイントに流し、Kinesisの中でシャードの中に。分析を行うkinesisアプリケーション(基本的にec2で作られる)で処理を行い、DB等に流す。
- 実際にKinesis内部的にどうなってる？→基本的にブラックボックス、勝手によしなにやってくれる。
- Kinesisアーキテクチャ
- PartisionKeyを設定。処理はこのキー設定毎に行われる。
- 実際どういうふうに使えるのか。下図のような形で、リアルタイムでログのカウントランキングやアイテム毎の相関を取る事が出来る。
- Out Streamについて
- 実際にどういうふうにkinesisを使っているか。またこれからどういうふうに使っていくかについて図を交えて解説。
- システム概要
- 広告ログを分析するための基盤
- アドホックな分析＆定常分析
- ターゲッティングにも使う
- カジュアルなシステム要件
- 複数サービスのログをひたすら取り込む。
- 過去ログもひたすら取込、快適に分析。hot / cold dataの分析を両立。(興味に近いフレッシュな情報を出せるように)
- ターゲティングはベストエフォート。
- 2012年中頃の構成：
- 『MongoDBクラスタ、これは非常にかわいいやつでね。夜泣きするんですよ』
- しかしこの構成、ホットデータの分析はしづらい模様。
- 2014年現在：
- 基本的にFluentdが頑張ってくれた。マジ神レベル。
- 結果を格納するのはDynamodbに。
- 結構Fluentdが便利過ぎていいのだが、止まると大変。
- ターゲッティングのルールとして『この商品とこの商品データを見たらこういう提案をしよう、というのをFluentで対応している。ただちょっと手間が掛かる部分であり、仕組み上直近のXX分の状況を見るというのは難しい。柔軟にストリームを扱いたい。
- どこにKinesisを使っているのか？→検証中の話と前置きしつつ解説。デザイン的にはこんな感じ。
- 検証項目
- 求めているスループットは出るか？
- どれくらいの負荷で書き込めるか？
- 書き込み失敗時にどのような挙動になるか。ハンドリング可能か？
- KCL(Kinesis Client Library)での開発は楽か？
以下3点はスライド情報が緻密＆文字数がかなり多かったのでスライドそのまま掲載させて頂きます(´・ω・｀)w とてもタメになる部分ですね...。
ざっくりとした使用感 - Producer
ざっくりとした使用感 - Consumer
Kinesis移行に関して
- 要望とまとめ
- Kinesisのメトリクス、もっと細かく見たい。
- DynamoDB同様、batchWriteが欲しい。
- Kinesis、もっと使っていきましょう！
- そして東京リージョンも待ってます。
ふつうのRedshiftパフォーマンスチューニング
- 自己紹介：
- 某並列DBベンダーコンサルからクックパッドへ。現在はRedshiftを扱ってます。
- 昔はRubyの標準ライブラリにも関わってました。青木氏『どうやら「赤い(Red)もの」に縁があるようです。』
メガネも赤いw #awscasual
— TOM☁cloudpack (@tomyankuns) 2014, 4月 18
- Redshiftについて
- 今日カジュアルトークなので即パフォーチューの話をしようかと思いましたが少し基本的な解説も。
- 並列RDBMS：SQLが普通に使えます。
- Redshiftのアーキテクチャ：リーダーノードとコンピュートノードの構成。
- 並列単位はnode slice(処理プロセス)。一番小さいノードでも1ノード/2スライス構成となる。
- 行は分散キーのハッシュ値で決定する。
- Redshiftの典型的なシステム構成(一例)
- 典型的なRedShiftのシステムはこんな感じ。
- Redshiftには大きく2種類、トランザクションデータ(10億行、100億行のデータも余裕)とマスタ系データ(こちらの方が相対的にはサイズは小さい)が格納されていく。この2種類のデータを組み合わせて分析。
- 見る方としてはBIツールや人間が直にSQLを叩く等。またバッチ処理が定期的に動くかも知れない。
Redshiftに対する処理の種類としては以下が挙げられる。
オンライン (OLTP)マイクロ秒 更新あり
- Redshiftでは無理。無理。諦めて下さい。
- 具体的に言うと：
- リクエストの並列度が高いのは無理。普通のwebサイトのような秒間2桁以上はやめとけ
- 高頻度・細粒度で更新するのは無理、5分間隔追加位がギリ。
- 小さいテーブルに対する1行取得とかなら
オンライン(OLAP/tactical) 0.1〜数秒
- Sortkeyに当てろ：行を特定のフィールドで予めソートしておく。普通のインデックスみたいなもの。これを使って範囲を狭めておくしかない。
- テーブルサイズを実測して一番小さくしろ：圧縮エンコードで測る。data dicrionalyで見ることが出来る。
- 事前ジョインはあんま効かない(集計はOK)：先にジョインするとデータが大きくなるケースもある。
オンライン (OLAP strategic)数秒〜数分/バッチ 数分〜数時間
- ここからが本番。
- 全件取得しRedshift環境外で非並列処理を行う：問題外の頻出パターン。これはやってはいけない。データが少なければまだしも、1000万行とかだと死ぬ。
- 『データを移動したら負け』。データを一回DBに入れたら外には出さない。これはもっとも基本的な方針。
- 規模感の見積イメージ：雰囲気としてはこれくらい。
"100億行〜 マジヤバイ"www #awscasual
— chezou (@chezou) 2014, 4月 18
- 重要なリソース："マジヤバイ"のを扱うにはどうすれば良いのか
- Redshiftで最もボトルネックになりやすいのはノード間のネットワーク。ここをチューニングする。
- ネットワークは実測すると30MB-60mb/sec。つまり、CPUに比べると10000の1位の速さしかない。詰まるのは当然。なので、チューニングするのはネットワークから。
- ネットワークに負荷を書けないようにするにはどうするか。再分散を避ける。(テーブルデータを別のdistkeyに従って移動する事)
- どういう時に再分散が起きるか。joinとgroup by。ジョインキーがdistkeyなら再分散は起こらない。
- useridがJoinキーとなる環境ならそれで分散、分散後の環境でジョインすれば移動は起こらない。(必ずジョインする相手が同じスライスに居るので)
- ネットワークを節約する＝再分散を起こさない＝分散キーを選択。
- 目印はDS_DIST_NONE。EXPLAINコマンドを実行し、この印が出てきたらOK。これが出るまでやる。これは分散DBもだいたい同じ。再分散させないのが重要。
- チューニングでは分散キーを選ぶ事に時間を費やす。(青木氏曰く)Hadoop嫌いだけど、理由は分散キーが無いからw
- 『データを移動したら負け』というのはRedshift内外の移動もそうだし、このノード間移動でも当てはまる。分析したいデータはrsに入れる。入れたら出さない。これが重要な考え方。
という訳でRedshiftチューニングに関するセッション終了。『データを移動したら負け』という至極シンプル且つ重要なポイント、及びその改善に至る解説はとても参考になりました。
時間が少し空いたので、青木氏の前職にまつわる小咄がありました。米国のTeradata Aster及びOracle本社の近くには空港があるのですが、その空港の3文字コード(※『空港コード』と呼ぶのかな？)、実は『SQL』なのだそうです。(※トリビア)
AWS使用がもっと楽になるネットワーク系の新サービス at VPC,ELB,CloudFront,Route53
- 発表・登壇：ARAKI Yasuhiro(TwitterID:@ar1)さん
発表資料
講演メモ
アマゾンデータサービスジャパン(ADSJ)の中の人から、SA荒木さんによる登壇。
こちらについては上記資料をそのまま見て頂く方が良いでしょう。というか荒木さん曰くとても重要な改善ポイントなんだけども『細かすぎて伝わらない』ネタについて行けなくなる事もしばしばw 代わりと言ってはなんですが、今回診サービスとして発表されたものについて、弊社エンジニア陣が言及しているエントリ群を以下にまとめておきます。上記荒木さんのスライド資料と下記の関連エントリを併せて読む事で理解もより一層、深まることでしょう！(ｷﾘｯ
荒木さん曰く、ELB Logging、ELB PFS、CloudFront SNIの3点については是非すぐに、勉強会から帰って来たら即試して見て欲しいものだそうです。お近くに確認する環境をお持ちの方は是非とも試してみてください。
- VPC Peering
- ELB - Logging
- ELB - Connection Draining
- ELB - PFS, SOP
- CloudFront - EDNS-Client-Subnet
- CloudFront - SNI
若干の小休止の後、LTコーナーへ突入。計4本、こちらも本編セッションに負けず劣らずの『カジュアル』度合いでした。
LT
LT1: EC2 + Spot Instance + Spark + MLlib で実現する簡単低コスト高速機械学習
- 発表・登壇：やまかつ(TwitterID:@yamakatu)さん
SparkはSpotInstanceと相性よし！ #awscasual
— ARAKI Yasuhiro (@ar1) 2014, 4月 18
SparkはEMRでもさっくり立ち上げられますよ https://t.co/DjULXMkfIP #awscasual
— Kenta Suzuki (@suzu_v) 2014, 4月 18
ほうほう。https://t.co/kiGuL7LI0e #awscasual
— Shinpei Ohtani (@shot6) 2014, 4月 18
LT2: 5分でできる ebfly
Elastic Beanstalk, 簡単にServletとか試すのに使ってます #awscasual
— Kenta Suzuki (@suzu_v) 2014, 4月 18
ebflyこれか！ http://t.co/7CleRxoPVS #awscasual
— con_mame (@con_mame) 2014, 4月 18
「ここでしばらく待ちますができあがったものが隣のリージョンに用意してあります」メソッド #awscasual
— Aki (@nekoruri) 2014, 4月 18
LT3: Logging and Data Analysis on .NET Framework with Redshift and DataPipeline
LoggingはETWでやってるのねー #awscasual
— Shinpei Ohtani (@shot6) 2014, 4月 18
graniはsumologicをつかっているがRedShiftをつかいたくなった #awscasual
— ARAKI Yasuhiro (@ar1) 2014, 4月 18
LT4: AWSメインの会社に転職したので数少ないAWS経験の話もしくは個人検証してるCloudSearchの話。もしくはその両方
- 発表・登壇：池田朋大(TwitterID:@mikeda)さん
某社の構成だだもれｗｗｗｗｗｗｗ #awscasual
— Aki (@nekoruri) 2014, 4月 18
副業禁止⇒焼肉支給でインフラ構築 #awscasual
— Aki (@nekoruri) 2014, 4月 18
今日一番カジュアルらしさある #awscasual
— 松本 勇気 (@y_matsuwitter) 2014, 4月 18
まとめ
という訳で、『カジュアル』らしさ全開の『AWS Casual Talks #2』最後まで楽しめました！個人的にもRedshiftに関するセッションは普段使いしている事もあって興味深く拝聴出来ましたし、Kinesisについても興味津々でしたので有意義なものとなりました。(欲を言えば、AWS Pipelineについては実際どういうふうに取り組んでいるのか、辺りも聞けるとより嬉しかったかも...)
次回第3回も可能であれば是非お話を聞いてみたいところです。(でも競争率高そう...w) 主催者及び発表者、関係者の皆様、ありがとうございました！
![[レポート] インシデント発生に備えるための議論をする tabletop「Incident response tabletop: Supply chain」 #GHJ205-R #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[レポート]re:Invent 2024のEXPO会場で救急セットを作ったりして #GiveBack しよう #AWSreInvent #ACT126](https://devio2024-media.developers.io/image/upload/v1733389602/user-gen-eyecatch/myjtprkzjjcwvxmf8enu.png)
