JAWS DAYS 2015で発表してきました
JAWS DAYS 2015でData Engineering at VOYAGE GROUPという題で発表してきました。運営の皆様、聴きに来てくださった皆様、どうもありがとうございました。
内容としては行動ターゲティング基盤をどのようにAWSを利用して実現しているのか、という話です。以下の課題に対して、どのような技術選択をして、運用をしているかというのがメインの話でした。
- なるべく速く書き込みたい。ユーザが何かをみたら、すぐにターゲティング可能な状態にしてほしい。反映が速ければ速いほどいい。
- 案件や対象ユーザが増えても、システム全体が問題なくスケールすること
- 読み込みが安定して低レイテンシであること。できれば5ms以内。
なかでもDynamoDBの運用、バッチとストリームの使い分け、といったところについて重点をおいています。スライドには乗っておらず、口頭で補足した部分もいろいろとあったので、ここにメモ程度に書いておきます。
DynamoDBのパーティションの話
最近、AWS Black Belt TechシリーズのDynamoDBの資料が更新されました。
www.slideshare.net
54枚目のスライドで、パーティションとCapacityの関係についての資料があります。DynamoDBの内部ではデータはそれぞれパーティションに分割されて保存されています。hash keyによってどのパーティションにデータが割り振られるかが決定されます。データ量に応じてパーティションの数が変動するようになっています。ここで、プロビジョンドスループットは各パーティションに均等に割り振られるようになっています。したがって、パーティションの数が増えている状態で、プロビジョンドスループットを落としてしまうと、1つ1つのパーティションのスループットが低い状態になってしまい、エラーが起こりやすい状態になります。というのが上のスライドです。したがって、
ということを気をつける必要があります。このあたりはdynamic-dynamodbの設定で、例えばスループットの最小値を決めておいたり、現状のキャパシティの3割増しのスループットを維持するようにする、などの工夫をするとよいでしょう。アプリケーションによってこのスループットの波というのは異なると思いますので、それぞれの環境に応じてこの辺りは調整するとよいです。ちなみにパーティション数の計算式は テーブルの操作のガイドライン - Amazon DynamoDB にあるので、自分のテーブルがいくつのパーティションの分割されていて、スループットが変わるとパーティション数がどう変わるのか、といったあたりを把握しておくとより振る舞いを理解しやすいです。その他DynamoDBのモデリングとパフォーマンスについてはre:Invent 2014の
(SDD407) Amazon DynamoDB: Data Modeling and Scaling Best Practices | … が参考になります。
近況と所感
実はJAWS DAYS初めての参加だったのですが、色んな方に会えて楽しめた一日でした。去年から業務ではマネージャーっぽい仕事をしていたのですが、もっとコードを書きたいですという話をしてまたコードを書く仕事をメインでやることにしました。*1なので、今年はより一層コードを書く時間を増やしてばりばりと手を動かしていく予定です。
それと、 今年度もお疲れ様でしたの会 on Zusaar というのを3/31にAJITOでやります！ビールを冷やしてお待ちしておりますので、お気軽に遊びに来てください。
*1:端的にいうとマネージャーをやめました
JAWS DAYS 2015で発表します
JAWS DAYS 2015で弊社でのデータエンジニアリングについて発表します。3/22の11:10から発表予定です。
Windowsで外付けHDDに書いてもらったファイルをMacで読み込む必要があったので調べた
brew install ntfs-3g
sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig
sudo ln -s /usr/local/Cellar/ntfs-3g/2014.2.15/sbin/mount_ntfs /sbin/mount_ntfs
brew install osxfuse
sudo /bin/cp -RfX /usr/local/opt/osxfuse/Library/Filesystems/osxfusefs.fs /Library/Filesystems/
sudo chmod +s /Library/Filesystems/osxfusefs.fs/Support/load_osxfusefs
あとはマウントする。
sudo mkdir /Volumes/extdisk
sudo mount -t ntfs -o nobrowse,rw /dev/disk2s1 /Volumes/extdisk
参考:
http://coolestguidesontheplanet.com/how-to-write-to-a-ntfs-drive-from-os-x-mavericks/ http://www.yansite.jp/ntfsrw2.html
年報 #vgadvent2014
気がつけばもうアドベントカレンダーの季節。今年も振り返りをしてみようと思う。
この記事はVOYAGE GROUP エンジニアブログ: Advent Calendar 2014の12/18分の記事です。 http://tech.voyagegroup.com/archives/7941760.html
去年も書いた振り返り記事: http://suzuken.hatenablog.jp/entry/2013/12/24/220213
書いていたら随分長くなってしまったし9割5分くらい自分の振り返りになってしまったしこれは最早ポエムに近いので、面白く無いかもしれない。3行に要約すると
- 分析チーム切り出した。課題多いけど着実に進んできている。
- マネージャーっぽくなりつつ、相変わらず分析基盤を作るエンジニアをやっている。よりインフラよりのこともし始めた。
- 初めて技術書の執筆に携われて、大変だったけど良い経験になった。
1-3月: 分析基盤グループを切り出し
広告周りのデータをもっと活用できるようにしたい。そういう要望から、私の所属しているチームが切りだされ、リーダーになった。ターゲティング基盤の構築に加えて、本格的にデータの分析をするための仕組みづくりを開始した。元からつくっていたDMPといわれるものの使いやすい部分を切り出せば、技術的にレバを効かせつつデータを活用できる仕組みが作れるのではないだろうかというのが発端だった。
Web広告の裏側で扱われているデータは、大きい、というより多い。かつ、スパースで、関連を見出すのに時間が掛かる。全量を使って解析したい。結果反映までの時間を短くしたい。そして最終的に広告効果をあげるところまでつなげていきたい。じゃあどうするか、組織をつくろう。そして分析をする文化をつくろう。これが最初の試みの始まりであり、今も変わらないスタンスである。
9月に行われた「サーバ／インフラエンジニア養成読本」のイベントでのプレゼン http://www.slideshare.net/suzuken/ss-38865046 でもこのあたりに触れているように、常に問題意識としてあったのは、データを活かす組織づくりだった。解析専任のメンバーもこのときはいなかったし、ただただデータを綺麗にするということだけが決まっていたようなものだった。もともといわゆる広告に利用するターゲティング基盤 *1 をつくっていて、その上でより広告主とメディアに対して双方のためになるような仕組みをつくることを考えていた。そのためにはデータをみて、そのための組織をつくって、よりロバストでデータに対して反応しやすく、それが広告システムとして息づき、新しい施策がどんどん取り入れられていく。そういう仕組をつくろうと思っていた。この課題に対して、エンジニアリングとしての無駄を省きつつ効率的に、かつ、分析タスクに対しても深くそして柔軟に取り組める組織が必要だった。なので、この1月のタイミングでそういう動きになった。というのがこのころの背景だった。
余談だが、こういったWeb広告システムの裏側を支える事柄というのは、なかなか表に出づらい。まぁなんというかとてもロジックが業務ドメイン直接なところが大きいのでしかたないという面もある。のだが、いわゆる分析チームをつくる、データ分析基盤をつくり分析を加速させていくという面については、一般的な技術的かつ組織的な課題として切り出して議論できる部分は多い。もっとこの領域については事例なり知見なりが表に出てくればよいと思っている。というのと、それに加えて文化を作るというのは実に面白い話でもあって、今年は幾分そういうところに時間を割いていた。あとは組織縦割りの弊害とか、各組織にまたがるように知見を共有したりシステムがうまく連携していくにはどうしたらいいんだろうかとかそういうことをむにゃむにゃ考えていた。もちろんパラダイムとしてはmicro servicesみたいな方針はあるのだが、それよりも大枠でシステム間の連携や知見の共有がうまくできていないという背景があった。このへんは組織によって変わる話だと認識しているが、いま振り返るとそのあたりが悩みの種だったなぁと思う。チームごとに分析のownershipが持てているか、などなど。
それからこのへんでImpalaとかPrestoの検証やったり、Elasticseacrhを触ったりしていた。DynamoDBのGSIすごいなーとか。ターゲティングシステムを柔軟にできるようにしたりとか。システム連携したりとか。JVMのFull GCと戦ったりとか。気がつけば評価の業務とか、採用周りとかそういうのにつかう時間も増えてた。これから毎日会って、一緒に考えて、ものをつくっていく人を選ぶというのは大変なことだなと感じたりした。あとJVMのFull GCと戦ってた。
それと、（嬉しい事に）このへんでログ解析本書くのが決まって、打ち合わせとかしてた。
4-6月: 新卒の配属と、マネージャー業
新卒3年目となった。早いような気がしていたが、今は既に年末である。チームに（お酒好きで知識欲旺盛でPythonistaの）新卒サイエンティストamacbeeが入ってきたり、将棋好きで最近ラジコン？にはまっているプロキシエンジニアrail44が入ってきて、ますます活気づいてきたのがこの時期である。そうか、8ヶ月も前だったか。
このころ前年からの動きがちょっと表に出た。杉山先生に来て頂いてディスカッションを深めることができはじめたのもこの時期のこと。 http://voyagegroup.com/news/press/2014/513/ この取組自体についてはほとんど外で触れられていないので簡単に説明しておくと、アドテクノロジー領域でのデータをどのように見ていくか、そしてどう活用していくか。かつそのなかでどういう手法があるか。といったところをディスカッションするというようなことをしている。まず「なぜそのアプローチをしたか」よりも「なぜその問題にアプローチしようとしたか」のほうを私としては重視している。ドメインの知識がないと判断しかねる場面も多いのだが、それはエンジニアで言うと「良さそうだったからその機能を作りました」、というニュアンスっぽさがある。そうではなくて、分析というのは「意思決定をすること」そのものに価値があると私は思っている。なので、あるロジックによって広告効果を上げることができたとしても、「なぜその問題にアプローチをしようとしたか」が抜けていると、崩れる。端的にいうと、バランスがよくなくなる。私達はたくさんのパートナーの方々に支えられていて、その上で広告を配信するというサービスを提供している。なので、「なぜ」とその倫理観が大事だと考えている。その前提にたった上で「ではどういう手法で」ということのディスカッションを深めるのがこの試みのメインとなっている。私たちのような産業の分野において学術の領域とうまく関わりつつ、知見を活かしていくというのはよく言われることではあるが、そう簡単に進まないというのが実情である。少しずつ、問題の枠組みを落とし込みながら興味深い問題を作っていく過程が個人的にはとても楽しい。
ここは私自身の趣向だが、エンジニアがOSSにPull Requestを送るように、学術の分野にももっと気軽にフィードバックできるようにしていきたいと考えている。これは温度感の問題かもしれない。私自身研究室にいた時に、実際の現場のデータがあればもっとこういう知見が得られたかもしれないな・・・と思うことがよくあった。逆に今企業にいって、手元にデータがあるのに逆に活かせていないと感じる部分がある。まだまだ道半ば（いや、どこまでいっても道半ばなのだけれども）ではあるが、こういう取り組みは積極的にしていきたいと考えている。正直今分析したくても着手できていない部分がまだまだたくさんある。というかやればやるほど、もっとやらなければならない部分が見えてきている。こういう領域に興味がある人は是非一緒に仕事をしたいし、私達としても加速したいと考えている。何より、データに向き合うのが本当に楽しい、と感じられる時間がある。そういうところを価値に変えていくのが、私のチームの仕事でもあるし、私自身の問題意識でもある。
といいつつ、手元ではターゲティング基盤の改良をしなければならなかったり、ETL業をひたすらやっていたり、まぁ手を回しても手が足りない、というような季節だった。fluentdをベースとしたストリーミング処理の環境とバッチ処理との適当な使い分けをデザインしたり、実装したりした。fluentdなかったらリアルタイムに近い処理というのはなかなか実現できなかったであろうということは去年もいくつか記事を書いた。新卒エンジニア研修とかもやってた。ゴールデンウィークは息抜こうと思ってたけど、執筆のが全然終わらなくて結局1日休めただけであとはひたすら家かカフェで原稿書いてた。本当に日常的に原稿書いてる方々はすごい。尊敬しか無い。技術的な内容で、普段やっているようなログ解析の話を書いたのだが、それでもまとめていくには随分時間がかかった。
原稿を書くというのは本当に良い経験だった。自分の今までやってきた仕事をまとめる良い機会でもあったし、文章で伝えるということに時間をかけて集中して取り組める機会になった。今読み返しても「伝わりづらいな・・」とか「もっとここ検証してから書きたかったな・・・」とか反省点はいろいろ出てくるのだが、伝えたいことは文章に盛り込んでいる。でも、2000円もかけて本を買ってくださった方々に、「こんな本買わなければよかった」って思われるのではなくて「買ってよかった、読んでよかった」と思われるものを書くというのが常に脳裏にあって、空き時間はずーっと原稿のことばかり考えてた。自分は未熟だな、ということばかり感じた。そういうことを経たあとに、今まで読んできた技術書を読み返したり、私が勉強してきた本を書いてくださった方々に対して何ともいえない感謝の念が湧いてきた。それと同時に、「ああ、私にはこんな本を書けないな」と思うような本をたくさん読んできているのだということに気づく。例えばSICPとか、私がおじいさんになるまでプログラム書いてても、到底書けるようにならないと思う。などなど色々感じることはあったし反省点も多いのだけれど、技術書を書くということに挑戦できて総じて良かったと感じている。*2
あとはElasticsearchのクラスタが大きくなったり、Sparkの検証したり、Kinesis触ったりしてた。バンディットアルゴリズムの勉強会とかを開いた。SICPのamb評価器を書いていて悟りを開いたりした。 https://twitter.com/suzu_v/status/465856366830030849 あと、可視化ツールが気になったので確認したりした http://suzuken.hatenablog.jp/entry/2014/06/05/130202 あとは若さ溢れる会があったりした http://www.zusaar.com/event/11397003 あと初めてHadoop SCRにいった。SparkのRDDについて掘り下げてて有意義な会だった。あとNorikra仕込んだのもこの時期だった。
7-9月: ターゲティングシステム改善再び
ターゲティングを管理するための系統があまりよくない形だったのでこれをしっかり作りたいな、というようなところからスタートした。いわゆる管理画面で、その後ろでHiveだったりstreamingが走るような機能をもっているのだが、システム全体として結果の出力が見づらかったし、疎結合にできるところが全然できてなかったりした。そろそろこれは退役できそうではあるのだが、まだ動いてる。今考えると半年掛かりだったのだな・・・。
このころにDWHについて考えなおしていて、そのメモが残っていた。突っ込みどころが多いが、このときはこういう点でいろいろ悩んでいたということがわかる。意外と検討をしたメモを残すというのはこうして見返すと面白い。
* 非構造化データ + 大規模ならHadoop一択なのだが、分析タスクなどは量も収められるし、Redshift的なものに収めたい。がしかし、過去ログのスキーマなどもがつっと整理しないと運用に載せることができない。
* この観点は最近だとHadoopにも同じことが言えて、Parquetなどを採用したい場合にはテーブル形式を決める必要がある。テーブル構造を変えるにはマイグレーションが必要になる。これを避けたいならORCfileにするのが現時点では良さそう。となるとHive 0.13を使いたいが、EMRはamiの更新が遅いので0.11しかつかえない・・・
* EMRは運用でいろいろハマる。楽だけど、それ以上のことができない。EC2上でEMR的なことを自前でやるほうを検討する時期かもしれない。
* ETL処理だけやらせるならいまのEMR運用でも良い。分析となると・・。と考えるとRedshiftに収めたほうがやはり楽だろうか。悩ましい。
* Hadoop界隈、ここ1年で急速に構造化データも束ねて扱えるように、かつインタラクティブ性を増すための仕組みとしてMPPのデザインを取り入れているため、いわゆるRDB側のMPPとHadoopクラスタ上（に問わないものもあるけど）でのMPPのどちらを選ぶか、というのが今後にとって大きな分岐になる。あとはBig Data as a Serviceに任せるか。
2014/07/09 のメモより
あとはこのころ悩んでいたこととしては、インフラエンジニアの権限についてだった。私のチームには専任のインフラエンジニアがおらず、依頼ベースでサーバなりミドルウェアの設定をして貰う必要があった。専門的なメンバーに問題について検討してもらえるのは有難いことではある。ただ、制約があると、それを越えるための細かな工夫をすることで実現していくのがエンジニアの習性なのだろうか、私もそれに漏れず、自社のインフラ管理をくぐり抜けて「なんとかうまくやる」仕組みを作ってしまっていた。なんというか、これではお互い不幸だな、と思う部分が増えたので、結局のところ10月以降に自分の担当しているプロダクトの領域についてはインフラエンジニアとしての仕事も巻き取ることにした。いわゆる、root権限のないインフラエンジニア業のようなことをしていた。*3ちなみにkatzchangには「さっさと巻き取ったほうが良い」と1年以上前から言われていたので、結果その通りになったなぁという感がある。
8月末にはエンジニア向け学生インターンTreasureの講師業を一部分担当した。前日アドベントカレンダー担当のco3kことえびちゃんの素晴らしい記事 http://co3k.org/blog/vg-security-intern-2014 からも雰囲気が伝わるかもしれない。去年に引き続き、brtriver先生の講義は相変わらずわかりやすかった。しかも去年の内容と比べると2倍？くらいの内容になっていたのだが、参加してくれた子たちが真剣に取り組んでくれたおかげで、今年のインターンをつくり上げることができたなと感じている。私はPHPでAPIサーバを実装する話や、TDD Bootcampなどをした。今回はTDDの課題をペアプロで進めてもらう形式をとった。学生のみんなが設計をするスピードと精度が徐々に良くなっていく様子を見ることができた。そして私自身も講義をしながら勉強をさせてもらったという気持ちが強い。教える度に、ゼロから自分がプログラミングを始めた時のことや、学んでいる過程のことを思い出したりする。
この時期にログ解析本が発売された。感慨深かった。
http://suzuken.hatenablog.jp/entry/2014/07/18/084555
9月には出版イベントもあって、自分の書いた章のダイジェスト版を発表させていただいた。パネルディスカッションが楽しかった。
http://suzuken.hatenablog.jp/entry/2014/09/11/210059
10-12月: インフラエンジニア業加速
先に書いたようにインフラの巻取りを開始した。ちなみに今もやっている。
このタイミングであるプロダクトを別々のAWSアカウントに移すことになった。そこで、私の担当しているプロダクトを別のAWSアカウントに移行することに。non-VPCな環境からVPC環境での移行でもあった。そして今まで構築していたもらったものを新環境の方に構築し直すことにした。Puppetのmanifestを書くところから初めて、監視の整備も新規にやった。それまでも断片的に多少は知識があったのだけれど、それまで色々と助けて頂いていたので、やってみると知らないことがたくさんでてくる。IDCGメンバーや @katz_arc や @mass に聴きつつ、無事に進めることができている。
このあたりはある程度まとまったらまとめてどこかで話をしたい。
あとはre:Inventに参加してきた。
- http://suzuken.hatenablog.jp/entry/2014/11/09/132834
- http://suzuken.hatenablog.jp/entry/2014/11/16/222447
- http://suzuken.hatenablog.jp/entry/2014/11/13/112730
見たいものを絞っているが、まだビデオとスライド見切れてない。re:Inventについては技術的な話については色々なところで書かれているので割愛するが、参加できてよかった。re:Inventは去年も参加していて、今年は変化を見て取ることができた。
re:Inventにいって最も反省したのは、自分がもっと成果を出すことのできる環境を作れるのに作れていないと感じたことだ。AWSのエンジニアの方々と話していて素晴らしいなと思う点は、全員がプロダクトを自分のものとして、主語として語ることのできるところだ。彼らはそれをオーナーシップと言っていたりしていて、組織的にプロダクトを作ることができている。あんなの大きな会社でできているのに、自分たちはプロダクトのオーナーシップを大切にできているかと、出張中ずっと自問していた。Kinesisの開発チームの方と話を聴いたときにそれを鮮明に思った。「インフラチームで問題が起きたらどうするのか？Kinesisのようなhigh throughputなサービスを維持しなければならない場合にはインフラの問題も頻繁に起こると思うが、どのようにオーナーシップを引いているのか」という質問をしたら、Kinesisのエンジニアは当然KinesisのSLAを守るためにあらゆる努力を尽くす、もしインフラチームができていなかったらインフラチームは自分たちのインフラにオーナーシップを持てていないということだから、責任をもってやってくれというコミュニーケーションをとっている、という答えだった。これは当たり前のことのように思えるかもしれないけれど、実は「隣のチームもああいう事情があるんだろうな」とか「それは私達の責任じゃないからお客さんには申し訳ないけどしかたないな」とかそういう気持ちになってしまうときというのが少なからず自分の中になかったか。そう考えると自分たちのプロダクトに私はまだまだ責任をとれていないと思ったし、改善していくスピードを上げることができていないな、だめだなと反省した。なので、今回自分たちのプロダクト領域でインフラの仕事も巻き取ることにしたのはそういう理由がある。結果としてはやるべきことは3倍増えたが、改善のスピードは5割増しになった、というような感じがある。つまるところ、プロダクトが改善するスピードをあげていくことが、私のようなエンジニアの責任なのだと考えている。
12月の頭ごろに、社内で参加していたSICP読書会が無事最後まで終了した。読書会は問題を1問1問解いていくスタイルで進められていて、よっぽど面倒な問題で無い限りは解いた。メンターの @ajiyoshi には感謝しかない。本当にありがとうございます。評価とは何か、解釈とは何か。計算機科学を私は知らなかったということを正面から教えてくれた。この教科書に約2年間ほどしっかり取り組んで、自分のコードの書き方、抽象の捉え方、そして計算機に対する見方が変わった。そして未だによくわからない部分は残っていて、そのうち読み返したくなりそう。
そして、自分がいくら勉強をしても、きっとこんな本を書けるようにはなれないだろうなと思う。どういう熱意と思い入れと知識と体系づける力と集中力があったらこんな本を書けるんだろう。
あとはサブロク会議という社内のイベントに出ていた。会社の経営メンバー + 何人か、みたいなメンバーで経営課題と解決策を話し合う会議みたいのがあって、それに出てた。3回目だったけど、毎回一緒に組ませて頂いているメンバーが違うので面白い。が、なかなか自分の部署とか事業ドメインのところではない部分だと知識が足りなくて、本質的な意見が出せないというもどかしさもある。1,2回目よりは普段の情報量や考える時間が増えているからか、満足した議論ができた、気がする。
あとはDocker触ったり、とか。td-agent2にしたりとか。Sensuいれたりとか、BigQuery触ったりとか。MCollectiveが素晴らしかったりとか。細かいところでいくと色々やった。気が付くと手を動かす時間が削られていくので、検証のためのコードとかは暇があれば書いてる。暇をつくって書くようにしなければならないな・・と自戒した3ヶ月でもあった。
まとめ
徒然と書いてしまった。こうして振り返ってみると、全然やりきれていない点がたくさんある。ただその中でも、多くの方々のお世話になったからこそ、紆余曲折しつつ仕事を進めることが出来たのだなぁと感じている。本当に日々みなさまどうもありがとうございます。
次は最近Android化した同期エンジニアの @sayadroid です。お楽しみに。
AWS re:Invent 2014 breakout session 2日目
二日目もKeynoteとsessionがありました。メモを残しておきます。
参加したセッション
- SPOT305 -- Event-Driven Computing on Change Logs in AWS
- BDT401 -- Big Data Orchestra - Harmony within Data Analysis Tools
- APP303 -- Lightning Fast Deploys with Docker Containers and AWS
- GAM404 -- Gaming DevOps: Scopely's Continuous Deployment Pipeline
- SDD424 - Simplifying Scalable Distributed Applications Using DynamoDB Streams
新サービス類
気になったものだけ。
ECS: EC2 Container Service
- AWS | Amazon EC2 Container Service
- Expanding The Cloud - Introducing The Amazon EC2 Container Service - All Things Distributed
コンテナのマネジメントの仕組みを提供するもの。EC2インスタンスにあるものと同じように、containerに対してもIAM Roleやsecurity groupを適用したり、EBS volumeをできたりできる。apiではclusterの立ち上げと、taskとしてのcontainerの割り当てを行うことができ、高速にコンテナを扱うことができる。
Amazon Lambda
AWS Lambda - Run Code in the Cloud AWS Lambda
Lambdaはその名の通り、あのLambdaです。EC2インスタンスを自分で用意する必要もありません。手続きを定義して渡すのみ。そうするとそこに渡されたデータをよしなに扱うことができる。
所感
- これが今回の発表の中ではもっともdisruptiveなものだと思います。まだまだ取り組みの種の段階では有りますが、いわゆるworker側を簡単に、しかもfull managedなものとして提供できるようになったのは大きい。
- Kinesisが去年発表されたわけですが、Kinesis Applicationを自分で書いて、かつauto scalingの設定も自分でしないといけない。Kinesis Client Libraryにのっかると簡単にかけるものの、リソース管理をする必要はなくならない。それがこのLambdaだと、いわゆるLambdaを書けば動くわけです。
- また、今回、S3 notificationやDynamoDB Streamが追加されたことによって、いわゆるEventを受け取れるsoruceが増えました。例えばs3の特定のpathにfileがuploadされた際にその内容をparseして一部をDynamoDBにinsertする・・・というようなことが、EC2でworkerを立てなくてもできるわけです。
- fluentdからLambdaに渡してfilterとかexecっぽい処理はそっちに分離したいなぁと思ったり。
breakout session
SPOT305 -- Event-Driven Computing on Change Logs in AWS
it's all about timeliness and agility
最近のもろもろのupdateによってEvent-Drivenなcomputingが可能になってきたね！というセッション
- 写真共有サービスで登録しているユーザが画像をuploadするケースを考える
- event-drivenのanti pattern
- 全量をscanするような作りにはしないこと
- 1つ1つのイベントで大きな処理をしない
- 全量をscanするような作りにはしないこと
所感
- これは良い流れ、S3 notification便利っぽい
- DynamoDB Stream, S3 notification, Kinesis, SQSといったreal-timeな通知をする側と、そのeventを受け取る側(lambda, SQS, SNSなど)が今後拡充されていくんじゃないかと期待
- 例えばCloudTrailでs3に流れてきた
- batchでs3 bucketをscanしてその中にある何かを探して1つの小さなoperationしかやらない、みたいなopsを排除していきたい
BDT401 -- Big Data Orchestra - Harmony within Data Analysis Tools
SQSとかKinesisとかCloudSearchとか連携させて使うにはどういうarchitectureになるか、っていう話
所感
- 知ってる話ばっかりだったので割愛
APP303 -- Lightning Fast Deploys with Docker Containers and AWS
Dockerの中の人の発表
Dockerの基礎的な説明がメイン。今回のカンファレンスではコンテナに対する期待度が高かったようで、大人気のセッションだった。
- haproxy -> flask -> redisな構成をDockerでdeployするデモ
docker hostsが便利- どんなことをしているのかは awsapp/deploy.sh at master · nathanleclaire/awsapp みればわかる
imageでrollbackできるのは便利
rollback) docker hosts active ${DOCKER_HOST_NAME} run_app_containers_from_image ${REMOTE_IMAGE}:$2 docker hosts active default
remote hostsでも
docker psで確認できる
所感
- Docker自体の説明とデプロイ方法の説明だった
- 内容はGitHubに載っているのであれだけど、デモが手際よくてエキサイティングだった
- FlaskからTornadoに切り替えるデモとかなかなかおもしろかったというか、その発想はなかった
GAM404 -- Gaming DevOps: Scopely's Continuous Deployment Pipeline
Scopelyというモバイルのゲーム会社
- ざっくりいうと、Blue/Green Deploymentはごりっとしてるから中間っぽい感じの方法でやってるよという話
- blue/green deployment
- ２つの完全なクラスタ
- 完全な受け入れテストができること
- 問題
- CYAN deployment
- greenとblueを混ぜてみた
- canary releaseみたいなもの
- acceptance testsの知識は完全ではない
- stagingで
- 1つのelbをつかう
- warm upいらない
- dns変更しなくていい
- 多くのものを動かさなくてもいい
- ビルドへのアプローチ
- golden ami approach
- 全てのソフトウェアをamiにいれておく
- 起動時にデプロイ
- base amiを用意するものの、起動後のインスタンスにprovisionする方式
- golden ami approach
所感
- ゲーム企業とかだとユーザ体験に直にかかわるので結構センシティブなんだろうなと思った
SDD424 - Simplifying Scalable Distributed Applications Using DynamoDB Streams
DynamoDB Streamの話がメイン
- 話としては前のセッションにも出てたんで割愛
所感
- cross region replicationしたい要望ってどれくらいあったんだろう
- streamのインタフェースをKinesisに整えたのは素敵
AWS re:Invent breakout session 1日目
re:Invent 2014 breakout session 1日目
個人的にメモっておきます。
Keynoteでは、AuroraがでたりConfigだったりCodeDeployだったりがでました。細かい機能の話は参照しておいて、所感中心で。
聴いたセッションは以下のとおり。
- SDD406 -- Amazon EC2 Instances Deep Dive
- SDD415 NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine
- BDT403 - Netflix's Next Generation Big Data Platform
- BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon Elastic MapReduce and Storm
- APP402 -- Serving Billions of Web Requests Each Day with Elastic Beanstalk
新サービス類
Aurora
AWSのためにre-designされた、速くてスケールするMySQLです。*1 まだPreviewでusでのみ限定公開になります。
所感
- 銀の弾丸ではない
- ストレージとログのレイヤを既存のMySQLの構造から切り出してAWSのアーキテクチャにフィットさせているあたりかっこよい
- キャッシュがDBのプロセスの外に出たのは嬉しい、restartしても残るわけだし
- マルチマスターにしなくてよいほどにwriteが安定して速いといいなぁ（安直にマルチマスターの機能を追加するよりは、パフォーマンスをどんどん上げる方向に向いていって欲しいなぁと思った
- 「MySQLよりパフォーマンスが5倍向上！」がひとり歩きして、まだリリースされていないのに大変だなと思った
- つまるところ使ってみないとわからん
Code ManagementとDeployのツールいろいろ
所感
- この領域きたかー
- Amazon本体のCIの話 The Story of Apollo - Amazon’s Deployment Engine - All Things Distributed がいい話だったんだけど、1年で5000万回デプロイとかしてて尋常じゃなかった。この背景があるとサービス化したのも、思想的にわかる。
In the past 12 months alone, Apollo was used for 50M deployments to development, testing, and production hosts.
- 実際にどれくらいのユーザが使うかはわからないけどCIサーバの運用しなくなるならいいなと思った
- でもおそらくOpsWorksじゃないけど、全てのユーザがこれに乗っかるようなものではないだろうなあとも思う
- そう、やはり使ってみないとわからん
セッション
SDD406 -- Amazon EC2 Instances Deep Dive
EC2 instanceの話。
- EC2 instanceのProduct ManagerのJohnさんとKernelとかOS周りやってるAnthonyさんのセッション
- とりあえずKernel 3.8以降使っとけって言ってた
- ウェアレベリング - Wikipedia とかこのへんの話
- t2.microのCPU burstなんかについて、どういう設計思想でつくったか、みたいな話もあった
- PV-HVMがなぜPVより速いか、あたりについての解説
SDD415 NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine
機能周りは上に書いたのでQAのメモを貼っておく。立ち見でてた。
- RDS: MySQL -> auroraのマイグレートは簡単に
- バイナリフォーマットでコンバートできるように
- MySQLのコンパティビリティを壊してはいないから、既存ツールも動くはず
- Encryptionはサポート予定
- 開発用のローカルバージョンは出さない予定
- MySQL 5.6と変わらないからね
- MySQLの新しいバージョンにも追従していく予定
- Postgreサポートするか？
- 今日はないよw
- MySQLはユーザ多いからやった
- 可能だけどどこに今後サポートとするかによるかな
- スケーリングはシンプルに出来る
- dedicatedインスタンスは今後の展開次第
- network ioのコストは、殆どない。なぜならVPC内だから
- multi-masterはどう？
- それぞれのマスターノードしか用意出来てない
- 顧客の要望があるならやるかも？
- 現時点での見解としてはmulti-masterにする必要はないと思ってる
BDT403 - Netflix's Next Generation Big Data Platform
Netflixの解析基盤の話 in 2014。去年もごりごりいろんな発表合ったので、どんなupdateあるのかなと思いながらきいた。このセッションもほぼ満員だった
- 2013年と比較すると、Prestoの採用とHadoop 2への移行, Parquet FFへの移行というのが大きい話
- Parquet, Pig, Hive, Prestoにそれぞれcontributeした
- column position based access, Data type coercion, Null paddingなどなど
- Parquetへの移行の話
- 規模
- Hadoop 2への移行の作業について
- パッチあてた
- userのqueueを動的に階層化する
- 動的に公正な共有を行うようにした
- Genieからジョブをディスパッチする際に、Hadoop1と2を並行稼働させてそれぞれにジョブなげてた
- 今は全体をHadoop 2系に移行した。EMRだからmigrationはわりと楽だった。
- パッチあてた
- Prestoについて, アドホックな分析に利用してる。TBオーダでもインタラクティブに動く
- NetflixのPrestoへのコントリビュート: S3 filesystem対応、Parquet対応、ODBC driver改善、map / array改善、などなど
- Netflixがソフトウェアを選ぶ基準: ホワイトボックスであること
- なぜEMRを使うのか
所感
- 熱かった
BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon Elastic MapReduce and Storm
Yelpのなかの人のパフォーマンスモニタリング話
所感
- EMRとStormの話はそんなに出てこなかった
APP402 -- Serving Billions of Web Requests Each Day with Elastic Beanstalk
ほんとはDataDogのDocker Containerのscaleとmonitoringに関するセッションにいこうと思ってたんだけど会場が満員で入れず・・・ということでこちらにきた。
ThinkNearというMobileのRTB事業者さんのセッション。
メモ
- Elastic Beanstalkをばりばりつかってる
- 構成
- networkまわり
- tomcatがだいたい1000-1200ファイルくらい常に開いてる
net.core.somaxconnあげておく。4096にしてる。バーストしたらまずこれが枯渇する。net.ipv4.tcp_fin_timeout大事。timeout大事。ELB側も合わせて調整すること。- ELBはConnection Drainingの設定しておく。timeoutしたときにスムーズに外せるように。
- ログ周り
- ディスク
- EBS遅いからraid0してる
- tomcatのログはephemeralに書いてる
というのを全部構成するための設定がGitHubに載ってる。Yeah!
所感
- Elastic Beanstalkでがんばるとかまじか・・・と思ったがまじだった
- Hotkey問題、あるあるだった
- Elasticacheは外部キャッシュとしてはやはり速い。そしてアプリケーションのキャッシュはさらに速い
- ちょっと考えさせられた
- try and errorいろいろあれど、beanstalkでそれなりにさばけるところまで持っていくの、それはそれで戦略だなと思った
- それにしても俺得セッションだった
*1:かなり適当にまとめています
今年もAWS re:Inventに行ってきます&興味のあるセッション一覧メモ
追記 2014/11/14: スライドがupされていたのでみつけたものを追加。出れてないセッションを中心に確認したい。
今年もAWS re:Inventに参加して来ます。去年いってみて、興味あるセッションを見きれなかったり、新サービスのセッションが急遽追加されたりしていて、なかなかボーリュウムが有りました。今年も例に漏れず見たいセッションがたくさんあるので、ここにメモしておきます。あとでビデオやらスライドで見返すかも、です。
ちなみに去年参加したセッションは以下の記事にまとめてあります。
AWS re:Invent 2013で参加したセッション&聴きたかったセッションまとめ - すずけんメモ http://suzuken.hatenablog.jp/entry/2013/11/19/014517
とりあえず興味をもったセッション一覧
セッションの説明だけみて興味もったもの。日付順です。
"セッション名","日付","開始時刻"
"DEV301 -- Advanced Usage of the AWS CLI" "11/12/14" "11:00"
(DEV301) Advanced Usage of the AWS CLI | AWS re:Invent 2014
"SDD406 -- Amazon EC2 Instances Deep Dive" "11/12/14" "11:00"
"PFC307 -- Auto Scaling: A Machine Learning Approach" "11/12/14" "11:00"
"APP306 -- Using AWS CloudFormation for Deployment and Management at Scale" "11/12/14" "11:00"
(APP306) Using AWS CloudFormation for Deployment and Management at Sc…
"SDD414 -- Amazon Redshift Deep Dive and What's Next" "11/12/14" "11:00"
"ARC307 -- Infrastructure as Code" "11/12/14" "13:15"
(ARC307) Infrastructure as Code | AWS re:Invent 2014
"BDT307 -- Running NoSQL on Amazon EC2" "11/12/14" "13:15"
(BDT307) Running NoSQL on Amazon EC2 | AWS re:Invent 2014
"PFC305 -- Embracing Failure: Fault-Injection and Service Reliability" "11/12/14" "13:15"
"BDT306 -- Mission-Critical Stream Processing with Amazon EMR and Amazon Kinesis" "11/12/14" "14:15"
"SDD403 -- Amazon RDS for MySQL Deep Dive" "11/12/14" "15:30"
"BDT402 -- Performance Profiling in Production: Analyzing Web Requests at Scale Using Amazon Elastic MapReduce and Storm" "11/12/14" "15:30"
(BDT402) Performance Profiling in Production: Analyzing Web Requests …
"PFC306 -- Performance Tuning Amazon EC2 Instances" "11/12/14" "15:30"
"SDD419 -- Amazon EC2 Networking Deep Dive and Best Practices" "11/12/14" "15:30"
"APP309 -- Running and Monitoring Docker Containers at Scale" "11/12/14" "16:30"
"PFC304 -- Effective Interprocess Communications in the Cloud: The Pros and Cons of Microservices Architectures" "11/12/14" "16:30"
"SDD421 -- Amazon EC2 Purchasing Deep Dive and Best Practices" "11/12/14" "16:30"
"WEB401 -- Optimizing Your Web Server on AWS" "11/13/14" "11:00"
"APP315 -- Coca-Cola: Migrating to AWS" "11/13/14" "11:00"
(APP315) Coca-Cola: Migrating to AWS | AWS re:Invent 2014
"PFC402 -- Bigger Faster: Performance Tips for High Speed and High Volume Applications" "11/13/14"
"ARC401 -- Black-Belt Networking for the Cloud Ninja" "11/13/14" "11:00"
"SPOT305 -- Event-Driven Computing on Change Logs in AWS" "11/13/14" "11:00"
"BDT401 -- Big Data Orchestra - Harmony within Data Analysis Tools" "11/13/14" "13:15"
"SDD423 -- Elastic Load Balancing Deep Dive and Best Practices" "11/13/14" "13:15"
"PFC303 -- Milliseconds Matter: Design Deploy and Operate Your Application for Best Possible Performance"
"APP303 -- Lightning Fast Deploys with Docker Containers and AWS" "11/13/14" "14:15"
"SDD405 -- Amazon Kinesis Deep Dive" "11/13/14" "14:15"
"SDD413 -- Amazon S3 Deep Dive and Best Practices" "11/13/14" "14:15"
"BDT303 -- Construct Your ETL Pipeline with AWS Data Pipeline Amazon EMR and Amazon Redshift"
"GAM404 -- Gaming DevOps: Scopely's Continuous Deployment Pipeline" "11/13/14" "15:15"
"BDT305 -- Lessons Learned and Best Practices for Running Hadoop on AWS" "11/13/14" "15:15"
"FIN401 -- Seismic Shift: Nasdaq's Migration to Amazon Redshift" "11/13/14" "15:15"
"SPOT303 -- Building Mission Critical Database Applications: A Conversation with AWS Customers about Best Practices" "11/13/14" "15:15"
"GAM402 -- Deploying a Low-Latency Multiplayer Game Globally: Loadout" "11/13/14" "16:30"
"SDD407 -- Amazon DynamoDB: Data Modeling and Scaling Best Practices" "11/13/14" "16:30"
"ADV403 -- Dynamic Ad Performance Reporting with Amazon Redshift: Data Science and Complex Queries at Massive Scale" "11/13/14" "16:30"
"SDD401 -- Amazon Elastic MapReduce Deep Dive and Best Practices" "11/13/14" "17:30"
"ADV303 -- MediaMath’s Data Revolution with Amazon Kinesis and Amazon EMR" "11/13/14" "17:30"
(ADV303) Beating the Speed of Light with Your Infrastructure in AWS |…
"ARC202 -- Real-World Real-Time Analytics" "11/13/14" "17:30"
"BDT308 -- Using Amazon Elastic MapReduce as Your Scalable Data Warehouse" "11/14/14" "9:00"
"ADV402 -- Beating the Speed of Light with Your Infrastructure in AWS" "11/14/14" "9:00"
"ARC303 -- Panning for Gold: Analyzing Unstructured Data" "11/14/14" "9:00"
Docker関連セッションとDevOpsまわり、それからDynamoDBのデータモデリングと広告インフラの話は外さずに聴きたいところです。あとはパフォーマンス周り全般を聞く予定。
それと余力あればハッカソンに遊びに行こうと思います。
追記: 見たセッション
上に載せてなかったけど見たセッションのスライドもみつけたらはっておく
