#WEBエンジニア勉強会01 で発表しました
WEBエンジニア勉強会 #01 (東京都, 新橋) でお話してきました!
発表資料はこちら。
経緯
4 月中頃に知人の濱野 (@engineer_osca) さんから勉強会を開催するので時間があれば協力してほしいと連絡頂きました。開催は 6 月とのことだったので、5 月 20 日の JJUG CCC までは動けないけど、そのあとでよければ協力するよー、登壇でも LT でもなんでもやるよー、と安請け合いしてしまいました。懲りない人ですね。
資料は CCC のリプレイでいいかなーなんて思っていたのですが、開催趣旨をよくよく聞くと特定言語やフレームワークに依らない方が望ましい、枠も 30 分とのこと。スプリングブートの 50 分ものじゃだめですね。
運良く(悪く?) OAuth 2 についていろいろ調べながら四苦八苦していて、「OAuth 2 ってむずかしい…自分ならこう説明するのになあ」という想いが溜まっていたので、それを吐き出すことにしました。
目的
なかなか抽象度の高い勉強会タイトルだったので少々悩みましたが、以下を目的に設定しました。
- JJUG CCC の反省を活かすこと
- 聴講してくださった方が OAuth 2 を学ぶ際に自分と同じ遠回りをせずに済むようになること
- 新しい知り合いを増やすこと
1.については後述の KPT で。2.についてはアンケートがないので詳細は不明ですが、この辺りのツイートから察するにまずまず達成できたと思っていいのかな。
@garbagetown さんの OAuth2.0 の説明とても分かりやすいし、今後 OAuth2.0 勉強する時すごくやりやすくなったと思う #WEBエンジニア勉強会01
— bokken (@_bokken) 2017年6月2日
3.については、イベント後の懇親会などで数名と名刺交換してお話できたので良かったです。
KPT
以下、簡単に振り返り。
- Keep
- CCC でまとめたマスタースライドを使い回して作業を効率化できた。今後もマイナーチェンジはあると思うけど、飽きるまでは継続
- CCC よりもまとめをしっかり書いたら締まりが良くなった。継続
- 付録に参考資料を多数掲載したところ好評だった。継続
- Problem
- Try
- 聴講者からもっと質問を引き出してみたい。Slido を使ってみる?
Ask the Speaker
以下、登壇後やアンケートなどで頂いたご意見に対する回答。って言っても 1 件のみですが。
悪意あるクライアントにアクセストークンを渡してしまったらどうなるの?
当然、認可された範囲内でリソースオーナーの意図しない操作を実行される可能性があります。トークンは合鍵のようなものなので、信頼できないクライアントに預けてはなりません。
とは言え、下記のとおり ID/パスワード を預けるよりは遥かに安全ですね。
- くり返しだけど、クライアントは認可された範囲内の操作しか実行できない
- ID/パスワードを預けた場合、クライアントはやりたい放題
- クライアントにパスワードを変更された場合、リソースオーナーはどうすることもできない
- 認可サーバに連絡して当該クライアントに発行したアクセストークンを無効化できる
- (認可サーバがアクセストークンのリフレッシュを自動処理しない場合) トークンの有効期限が切れれば使えなくなる
トークンのリフレッシュや無効化は時間の関係上、説明できなかったので、とても良い質問だなと思いました。
感想
今回の感想はこれに尽きます。
登壇駆動勉強まじ捗る #WEBエンジニア勉強会01
— がるがべ (@garbagetown) 2017年6月2日
なんとなく分かった気になってスライドを書いて、RFC を読み返して間違いに気付いてスライドを直して、のくり返しでした。
発表の機会がなかったらここまでしつこく RFC を読み直さなかったと思います。貴重な機会をくださった濱野さん、ありがとうございました!
あとは、これですね…
ハラスメントだ、、、https://t.co/sK1zyudKKe
— がるがべ (@garbagetown) 2017年6月2日
16GB MacBook Pro と IntelliJ IDEA Ultimate をご用意頂ける企業様からのお声掛けをお待ちしております…
JJUG CCC 2017 Spring に参加しました #jjug_ccc
ずいぶん日が経ってしまいましたが拝聴したセッションの感想を書き留めておきます。
Vue.js + Spring Bootで楽しくフルスタック開発やってみた
うらがみさん。
フロントエンドの知識が皆無なので、後日検索するキーワードを拾い集めるくらいの低い意識で拝聴。あとで調べようと思った (けどまだ調べてない…) キーワードは
- Cordova
- vue-router 2
- Vuex
- axios
など。webpack もなんとなくしか分かってない。で、こんなこと思った。
この辺ひと通りさわってうらがみ色に染まろうかな… #ccc_g2 #jjug_ccc pic.twitter.com/SxVbhXsse7
— がるがべ (@garbagetown) 2017年5月20日
Gradle, Doma2, Vue はマイナーだったり開発リソースの弱さが気になって距離を置いていたんだけど、尊敬するエンジニアの皆さんが声を揃えて推すのでちょっと考え方を改めようかと。イミュータブル、バリューオブジェクトを多用するのも興味あり。
最後にデザパタの話。むかし Swing をいじっていたこともあって Observer パターンが超重要なのは納得だったけど、Visitor パターンと型とパターンマッチングの話に付いていけなくて “???” と思っていたら、うらがみさんがすでにブログに書いていた。Brian Goetz の Java にパターンマッチ入れるとしたらこんな感じ?という記事にも同じことが書いてあって、すごく勉強になった。
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介
FOLIO の伊藤さん。転職おめでとうございます!ドラム関連のツイートにいつも fav くださってありがとうございますw
履歴データのモデリングについて、よくあるパターンを丁寧に説明してくださって、とても分かり易かった。パターンに名前を付けるの重要ですね。
で、バイテンポラルデータモデルをネイティブにサポートする Reladomo (レラドモ) の紹介。XML によるエンティティ定義、ジェネレーションギャップパターンを考慮したコード生成という説明に会場がざわついていた (ように感じた)w
分かり易さと発表時間の関係だと思うけど、導入部分のみの説明だったので、この辺を疑問に感じた。
テーブル関連があったり複数トランザクションで更新かけつつ古いデータをフェッチするとどうなるんだろ?絵を描きながら手を動かしてみると楽しそう #jjug_ccc #ccc_g3
— がるがべ (@garbagetown) 2017年5月20日
Q&A や懇親会で聞いた話では表の結合も考慮されているとのこと。シャーディングもサポートしているようなので、履歴をシャードに追い出せば性能も出るのかな。
Eclipse Collection と同様、Kata があるのでやってみようと思った (まだやってない…)。
ヤフーの広告レポートシステムをSpring Cloud Stream化するまで
塩野さんと橋本さん。懇親会でたくさんお話しさせて頂いてありがとうございました!共通の知り合いがいることも判明したので、いつかご一緒できるといいですねー。
各世代のアーキテクチャと問題点、それを次世代のアーキテクチャでどのように解決していったのか、という歴史の紹介が興味深かった。
歴史と言っても第一世代は 2014 年の話で、わずか 3 年で規模もアーキテクチャもこんなに変わるのか・・・と唖然とするばかり。ビジネスがちゃんと成長して、成長に伴って解決しなければいけない課題が発生して、その課題をエンジニアリングで解決して、って理想的な環境だなーと思ったり、夜中に叩き起こされる毎日もつらいなーと思ったり ^^;
月に数回は複数人で半日かけてリカバリ…こみ上げるものがある… #jjug_ccc #ccc_a4
— がるがべ (@garbagetown) 2017年5月20日
MQ を挟んだストリーム処理は MQ を死守しなきゃいけないんだけど、その辺どうしているのか説明がなかったのでセッション後に質問。
4台でクラスタしてるけどそもそも死んだことはないとのこと!
— がるがべ (@garbagetown) 2017年5月20日
ちょっとやそっとでは落ちないことが分かったのが大収穫。こういう実績のお話を聴けるのがカンファレンスの醍醐味ですね :-)
Javaで実装して学ぶOAuth 2.0!
多田さん。連続登壇記録を伸ばし続けていて本当にすごい。
Spring で実装するとセッションが Spring だらけになるので意地で Java EE で実装したという漢気には誰もが惚れたと思う。あと、合間に挟んでくる CM の面白さとデモ失敗のほうがみんなの記憶に残ってしまったようなw
個人的に OAuth 2 をそこそこ勉強した状態で拝聴したので、とくに OLTU による実装の部分はとても面白かったんだけど、ほぼ無知、あるいは OAuth 2 ってトークン使って認可するアレだよねーくらいの知識だと、ちょっと厳しかったんじゃないかなーと思った。
そもそもなんでアクセストークンが必要なんだろー?って背景が導入にあると理解しやすいかも #ccc_e5
— がるがべ (@garbagetown) 2017年5月20日
ここでの経験が後日の自分の発表につながるのですが、それはまた別ポストで。
Java8プログラミング ベストプラクティス & きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する
きしださん。メガネかけているの初めて拝見したような気がする。かっこいい!
離散ウェーブレット変換とか循環ニューラルネットワークとか何も分からないんだけど、きしださん独特の声と話し方で説明して頂くとまったく怖くなくて、むしろ面白いのがきしださんのすごいところだと思う。挙句、オチがロマンだったり、ちゃんと働けだったりw
コーディングプラクティスは Java 8 オンリーかと思いきや Java 7 以前のものもそれなりに。ラムダで例外処理はあきらめていいんだ、って割り切れたのが収穫。
この辺りから体力の限界が迫っており当日のツイートも少なめ・・・
あと斜め前の席でやんくさんがばりばりスライドを書いているのが気になったw
VMの歩む道。Dalvik、ART、そしてJava VM
最後はやんくさん。
体力の限界と VM 知識の不足で聞いているだけになってしまったけど、そもそもなぜ Android は独自に VM を作ったのか、Oracle JVM とは何が違うのか、など分かり易く説明していただいて面白かった!こういう完全に専門外の話が聴けるのもカンファレンスの面白いところですね :-)
裏番組でおそらくここと同じくらい分からんセッションをされていた @tan_go238 さんがバイナリに足を踏み込んだ経緯は以前に伺ったことがあるんだけど、やんくさんはなぜこの道に踏み込んだんだろう?と思った (けど訊いてないので今度いつか機会があったら訊いてみよう) ←訊かないパターン
懇親会
で、懇親会。LINE 寿司がめちゃくちゃおいしかった。LINE さん、ありがとうございました!
ファッ??? #jjug_ccc pic.twitter.com/WLujAzDLhB
— がるがべ (@garbagetown) 2017年5月20日
登壇効果もあったのか、初めての方とも沢山お話しすることができてこれまでの懇親会で一番楽しかったと思います。ご挨拶させて頂いたみなさん、本当にありがとうございました!
自分は人のお名前とお顔を覚えるのが苦手で、頂いた名刺にはどなただったかメモった付箋を貼ったりしているのですが、せめてお相手にはそんな苦労をかけたくないと思ってツイッターアイコンのシールを用意してみたところ、なかなか好評だった。今後も続けよう。
がるがべさんの、名刺にTwitterアイコン貼ってくスタイルは画期的だと思った。それだよ、我々が求めていたものは。
— Hiroshi (@itohiro73) 2017年5月20日
今回は PRINTAIL というサービスを使ってみました。1,000 円前後とお手軽なので、気になった方は試してみてください。
二次会
で、二次会。バイナリ部屋に押し込められたこざけさんがしょんぼりしていたのが面白かったw
こざけさんは技術で殴れば黙ることが判明した
— いつもありがとうございます。 (@tan_go238) 2017年5月20日
あときの子さんがヒーローの存在に気付いてなかったりw
そういえば、かずひらさんご挨拶できなかったな?
— SAMMY(きの子) (@aa7th) 2017年5月21日
と言うわけで登壇から二次会までとても楽しい一日でした。また次回もよろしくお願いします!
JJUG CCC 2017 Spring に登壇しました #jjug_ccc #ccc_g1
はじめて JJUG CCC でお話してきました!
発表資料はこちら。
いろいろと反省点はあるものの、アンケート結果を見る限りでは多くの方に喜んで頂けたようでひと安心。
登壇の背景
今回の CfP は身辺が慌ただしかったために一度は見送ったのですが、締め切りが延長されたので応募したところ採択されました。
はじめての CCC なのでひとつずつハードルを越えようと当初は 20 分枠で応募しましたが、JJUG 幹事から 50 分で話せないかと連絡があり、ありがたくチャレンジさせて頂きました。今になって振り返ってみると 50 分でも足りないくらいだったので拡大して頂いてよかったです。
登壇のねらい
自分は準大手システムインテグレータに勤める中堅エンジニアであり、そんな立場からコミュニティに貢献できることはなんだろう?と考えた結果、非機能要件という固めのテーマと Spring Boot という技術的なテーマを関連付ける内容にしました。
技術には強いけど IPA とか ISO とかあんまり知らないなーっていう方々には、これらの固い資料って伊達ではなくて網羅性が超高いので有用ですよっていうことをお届けしたく、一方で新しい技術の導入に苦戦している方々には、こんな便利なツール類がありますよ (って上司を説得して採用しましょう!) っていうことをお届けできればと。
わざわざ休日に勉強会に来るような人は技術者が多いはずなので、非機能要求グレードが届けばいいなーと思っていて、アンケート結果を見る限りこのねらいは達成できたようです。
あとは資料が一人歩きして Spring Boot 導入にひと役買ってくれれば万々歳ですね。
KPT
以下、簡単に振り返り。
- Keep
- 当たり前だけどレビューとリハーサルは超重要なので継続。レビュー、リハーサルにご協力頂いたみなさん、ありがとうございました!
- 節目スライドに目標経過時間を書いておくメソッドは有効なので継続。あからさまに見せるとみっともない場合はスピーカーノート (後述) に書けばよさそう
- Problem
- スライドのレイアウトやフォントサイズなど本質的でないところに時間を掛けすぎた。今回の資料でマスタースライドはまとまったので次回以降は改善できそう
- テンパって当日まで家庭や職場がおろそかになった。公私混同もはなはだしい。猛省
- テンパって当日ディスプレイをミラーリング設定にしてしまいスピーカーノートが読めなかった。猛省
- Try
- ピンマイク、レーザーポインタ、黒曜石などを活用して身軽にプレゼンしたい
- 音楽や動画などのメディアをプレゼンに活用できないか (
<marquee>
タグをカクカク動かしたかった…)
Ask the Speaker
以下、登壇後やアンケートなどで頂いたご意見に対する回答。
非機能要求グレードは項目多くて見積もり地獄にならない?
あらゆる案件に非機能要求グレードを全量使うのはアンチパターンです。
ほとんどの案件は「社会的影響が限定されたシステム」になるので、IPA のそれを “竹” として、よりお手軽な “梅” やリッチな “松” とセットで提案するとよいと思います。で、契約できたら各項目を調節して再見積もり。
IPA や ISO の資料は実用性より網羅性重視なので、現場で活用する場合はテーラリング必須だと思います。
spring-boot-admin のほうが便利じゃない?
複数アプリケーションを一元管理したい場合は Spring Boot Admin も便利そうですが、以下の理由より取り扱いませんでした。
- 運用・保守に特化しており mappings など開発に有用なエンドポイントは見られない (たぶん)
- 自分が使ったことがない…
- 発表時間も足りなかった ^^;
Jasypt の鍵はどうやって守る?
暗号化した値をアプリケーションで複合しなければならないので、完全に守ることはできないと思います。自宅の鍵を二個にするのと同じで、攻撃の手間を増やして機会を抑制することが重要かと。
Spring Cloud だと spring-cloud-vault があって、このへんのソリューションになるっぽいですが、まだよく分かっていません。
TERASOLUNA って有償じゃないの?
TERASOLUNA Server Framework for Java (5.x) は独自のフレームワークではなく、Spring Framework を中心とした OSS の組み合わせです。既存の OSS では足りない機能は共通ライブラリとして Apache 2 ライセンスで公開されています:-)
スライドの字が小さくて読めなかった…
コード例のフォントサイズは先輩方のアドバイスに則って 24pt で書いていて、これより大きくするのは厳しそうです。
お手元で資料をご覧になれるよう URL をお知らせしていましたが、セッションが始まってから来られた方には案内が行き届いていませんでした。申し訳ありません。次回以降、備え付けのホワイトボードに書いておくなど配慮します。
タイトルが抽象的。性能要件の話を期待した
ご指摘のとおりですね。タイトルが細かくなり過ぎるとくどくなってしまうので、セッション概要あたりに明記すべきでした。改善します!
それはそうと、性能要件をフレームワークやライブラリで対応するという観点で研究するのも面白そうです。ぱっと思いつくのはキャッシュ、非同期化、負荷試験あたりかなー。
Actuator が向く場面と向かない場面を明記すると良い
こちらもご指摘のとおりですね。個人的には、システム負荷がそれほど高くなく、かつ運用・保守にそれほど大きな予算を割けない社内システムなどが最適と考えています。
さらに詳しく学ぶためには何を参考にすればいい?
Spring Boot ではなく Spring MVC になりますが、TERASOLUNA 開発ガイドライン を読まれるとよいと思います。kazuki43zoo さんの Qiita も必見です。
英語に抵抗がなければ、やはり 公式ドキュメント が間違いないです。http://www.baeldung.com/ も小粒な情報が多くて参考になります。
まとめ
長くなったので拝聴したセッションの感想は次ポストで。
JJUG CCC 初登壇、楽しかったです!心身ともにしんどいときもありましたが、チャレンジして本当によかったです。
JJUG 幹事各位をはじめ、ボランティアスタッフのみなさん、セッションに足を運んでくださったみなさん、お疲れさまでした。ありがとうございました!
@toru_inoue から食洗機を譲り受けた
タイトルですべて言っているけど周辺の知見などを。
TL; DR
- @toru_inoue から食洗機を譲り受けた (圧倒的感謝)
- AR アプリで設置シミュレーション
- らくらく家財宅急便は着払い不可
- 分岐水栓は自分で取り付けるべき
- 食洗機は全自動食器棚
経緯
加齢とともに肌から潤いが失われ、かつ家族が増えて水仕事をする機会が多くなり、冬になると手荒れがひどくてハンドクリームを手放せず、漠然と食洗機が欲しいなあと思いつつも安くないし場所も取るので二の足を踏んでいたところ、タイムラインに以下のツイートが流れてきた。
食洗機買ってからメッチャクチャ生活クオリティ上がったのだけれど、引っ越した先が大変現代的なお家で食洗機がビルトインされていて、半年くらい使った食洗機が倉庫で眠ってるので誰かもらってくれ(知人枠
— 殺意駆動開発 (@toru_inoue) 2017年2月19日
聞けば Panasonic の NP-TR8 という製品で、けっこうデカいけど、ざっと寸法を測ってみたところなんとか設置できそう。
パナソニック 食器洗い乾燥機(ブラウン)Panasonic エコナビ NP-TR8-T
- 出版社/メーカー: パナソニック
- メディア:
- この商品を含むブログを見る
戸棚からシステムキッチンの説明書を引っ張り出して確認すると自宅の水栓はタカギの JG 1230 という機種で、ネットで調べてみると CB-STKB6 という分岐水栓で Panasonic の食洗機を取り付けることができるらしい。
パナソニック(Panasonic) 分岐水栓 CB-STKB6
- 出版社/メーカー: パナソニック
- メディア: ホーム&キッチン
- この商品を含むブログを見る
急な話で他に検討漏れがないか不安はあったものの、この千載一遇の幸運を逃すまいと図々しく手を上げた。
準備
@toru_inoue 曰く、念のため電気屋に置き場所や水回り工事の相談をしたほうがよいとのなので、さっそく翌日仕事を休んで (ちょうど有給休暇を取る予定だった) 台所の写真を撮りまくってから駅前の電気屋に行って相談したところ、問題ない模様。
分岐水栓の取り付けを業者に依頼すると一万円くらいかかるらしく、自分で作業する人がどれくらいいるのか聞くと「そんな人はいない。うちの店で買ってくれれば五千円で工事する」と言われた。分岐水栓も一万円くらいするし、自分でやってみないことには費用に値する作業なのかも分からないので、検討します、とだけ言って帰ってきた。
帰宅してアマゾンで分岐水栓を注文した後、もらってきたパンフレットをぱらぱら眺めていたら設置シミュレーション用 AR アプリの存在を知った。
カタログの特定ページを開いて置き、AR アプリを通して見るとそこに食洗機が登場するという、なんと言うか想像の斜め上をいく仕様。
アップストアのレビューには悪いことばかり書いてあるけど、設置イメージを具体的に把握できたし、無駄に風呂やトイレに食洗機を登場させて笑えたし、個人的にはとても良かった。
分岐水栓の取り付けに必要なモンキーレンチとプライヤーは別の友人から借りることにして準備完了。
問題
迅速に配送の手配をしてくれた @toru_inoue から連絡。モノがデカいので家財宅急便になるけど着払いは受け付けていないとのこと。
配送料は四千円程度。いったん立て替えてもらい、後日精算することにした。
設置
で、実際にモノが届いたので設置。結論から書くと分岐水栓は自分で取り付けるべき。
これよりオペを開始する pic.twitter.com/E5M4nqnI77
— がるがべ (@garbagetown) 2017年3月5日
実際に使ったのはマイナスドライバー、ピンセット、プライヤー。モンキーレンチはアゴが小さくて使えず、どこかで何かが固着していた場合を想定して用意したゴムハンマーは使わなかった。
具体的な手順は分岐水栓の取扱説明書と上記ツイートの一連のメンションを参照してもらうとして、若干ハマったところだけメモ。
- 止水栓がちょっと固かった
- ご家庭ごとに場所や形状が違うので注意
- 固さはパワーで解決した
- レバーハンドルも固かった
- 製品によっては六角ネジなどを外してから引き抜くものもあるので注意
- 固さはパワーで解決した
- カートリッジも固かった
- ネットで調べてみたら外したレバーハンドルを差し戻して引き抜けとあったので、その通りにしたら無事に引き抜けた
- 分岐水栓の取り付けが少し難しかった
- ここをミスると水漏れの原因になるので注意
- きちんとハマっていないと分岐水栓側のハブという部分がくるくる回るので、これが回らなくなるまで軽く前後左右に揺すりながら下に押し込む。きちんとハマるとガチっと音がする
- 分岐水栓、分岐コックのナットが予想より大きかった
- あとから知ったことだけど水栓工事のナットは 28mm が標準らしい。モンキーレンチはアゴが 30mm まで開くものを用意する
- 分岐コック側のナットを押さえるために一本、分岐水栓側のナットを締めるために一本、計二本あるとよい
- 分岐コック側のレバーを手で押さえ、分岐水栓側のナットをプライヤーで締めることで対応した
なにか失敗すると家中水浸しの即クラシアン案件になる気がしてビビっていたけど、やってみたら思ったより簡単だったし、自宅の止水栓や水栓の知識も得られたので自分で作業して良かった。
ただしパワーで解決する場面が何度かあるので、そっち方面に自信がない場合は大人しく金で解決するのもよいと思う。
感想
雑に述べると最高なんだけど、なにが最高なのかよく考えてみた結果、これは全自動食器棚であるのだなと思い至った。
実際に食洗機を利用してみると食洗機導入前後の食器に関する手順は以下のようになる。
手順 | 導入前 | 導入後 |
---|---|---|
1 | 食器棚から取り出す | 食洗機から取り出す |
2 | 使う | 使う |
3 | ざっと水で流す | ざっと水で流す |
4 | 洗う | ほぼ自動 |
5 | 乾かす | 自動 |
6 | 食器棚に収納する | ほぼ不要 |
食洗機という名前から手順 4 が省略されるのは期待通りとして、5 と 6 も省略されるのは意外な体験だった。
手洗いの場合でも水切りカゴにひと晩ほど放置しておけば乾燥は自動化できるものの、水切りカゴは収納力があまりないので乾燥後はどうしても食器棚に戻す必要がある。一方で食洗機はそのまま食器棚として使える収納力があるので、食器を使った後、ざっと水で流して食器棚に収納しておけばなぜか翌朝にはピカピカになっているという感覚に近い。
以前に洗濯乾燥機を手に入れたばかりで興奮冷めやらない友人が「これがおれの洋服ダンスだ」と言いながら洗濯乾燥機から引っ張り出した洋服に着替えていたけど、あれと同じだと思う。
謝辞
脳が若返るような刺激的な機会を提供してくれた @toru_inoue さんに感謝いたします。後日開催予定のうどん会にて配送料を精算すると共に、謝礼として上質の白い粉 (隠語) を献上したい所存です。
JJUG ナイトセミナーに登壇しました #jjug
はじめて JJUG でお話してきました!
発表資料はこちら。
口頭で補足した内容を含めた要約は、なかやまさん のライブドローイングレポート (すごい!) にまとまっています。
Playのお話メモ #jjug pic.twitter.com/xfkBwj0H27
— なかやまさん (@nakayama_san) June 27, 2016
当日の会場の雰囲気や togetter を見る限り、お話したかった内容は大体伝わっているようで安心しました。
経緯
五月の中頃に「今度のナイトセミナーで Play Framework について話さない?」とお誘い頂きました。
誰よりもドキュメントを読んでいる自負だけはあるものの、Play2 や Scala の実践的な経験はなく、有意義なお話ができるか不安だったのですが、なかなか得難い機会だったので思い切ってお引き受けすることに。
準備
まず、以下のブログとスライドを復習しました。これからプレゼンやる人は必読です。
やるべきことはイメージできたので、続いて登壇のゴールを考えました。ひたすら考えました。グアムの海にぷかぷか浮かんでいるときも考えていました。
どんな人が、なにを期待して聴きに来るんだろう?どうなったら成功したって言えるんだろう?自分にしかできない話、プレゼン...そんなものあるのか...?本当に引き受けてよかったのか、これ?!ウオオオオアアアアア!!
みたいなことを悶々と考えて、最終的に「Play を正しく知ってもらうこと」をゴールに設定しました。
Play が作られた背景や目的、利点だけではなく欠点も正しく知ってもらって、みなさんが抱えている課題にぴたっとハマったときだけ Play を使ってもらって、それで「Play いいじゃん!」となれば最高だなー、と。
ゴールが決まればあとは資料作りです。
まず使い慣れている markdown と reveal.js で全体の構成を組み立てた後、作業環境の都合上 *1 一度 LibreOffice でスライドにしてから KeyNote で清書。その都度 @gakuzzzz さんにレビューして頂き、的確なご指摘を頂くことができました。本当に、本当にありがとうございます!
当日
計画性がないくせに細かいところが気になる性質が災いして、当日の深夜までスライドいじりに明け暮れていたので、スピーチの練習はゼロ。昼休みに会社の後輩に付き合ってもらったリハーサルはボロボロでした。
これはヤバい!と仕事(幸いヒマだった)そっちのけでスクリプトを書いて自席でひとりぶつぶつと練習しました。台本はスライドと同じくらい大事ということに気付いたのが今回の最大の収穫。
その後、終業時刻をややフライング気味に職場を飛び出して、青山のファミリーマートでスライドを最終調整。思いつきで小見出しスライドに経過目標時間や小ネタを書いてみたのですが、いろいろとリラックスできてよかったです。
本番のお話は...自分ではまずまず落ち着いて話せたと思っているのですが、どうだったんでしょう?録画はなかったようなので、なにかお気付きの点があった方はツイッターなどでお知らせ頂けるとうれしいです。
謝辞
まず、貴重な機会をくださった JJUG のみなさんに感謝します。当日の運営も含めて、本当にありがとうございました。
くり返しになりますが、資料をレビューしてくださった @gakuzzzz さん。何度も拙い資料をご確認頂き、申し訳ありませんでした。がくぞさんの協力がなかったら悲惨な結果になっていたと思います。本当にありがとうございました。
リハーサルに付き合ってくれたポリーさん、イッチー、ありがとう!約束どおり今度お酒をごちそうします。
貴重な時間を割いて私のプレゼンを聴いてくださったみなさん、感想をツイートしてくださったみなさん、懇親会でお話させて頂いたみなさんにも感謝です。頂戴した感想を活かして、次回があれば必ずパワーアップしたプレゼンをお届けします!
最後に、構想段階ではいつもぼーっと考え事をしていて、作業段階では毎晩夜更かししてふらふらしていたダメダメな夫・父親を支えてくれた妻と娘に感謝します。本当にありがとう!しばらく家事に専念します ^^;
Cloud Foundry ワークショップに行ってきた #cfws
04/18 に開催された Cloud Foundry ワークショップに参加してきました。
Open PaaS かつ PlayFramework 対応ということで Ruby で実装されていた頃から名前はよく耳にしていましたが、当時は PaaS をなんとなく制約の多い IaaS くらいにしか捉えておらず、あまり積極的にウォッチしていませんでした。
あれから数年が経って Docker や Spring Boot が登場した現在における PaaS の感触を持っておきたかったことと、なにより Pivotal Japan に行ってみたかったことから、業務をさっさと切り上げて参加してきました。
Introduction
30 分くらいと言いつつ 45 分くらい Cloud Foundry の紹介。
以下、当日のメモから特に印象に残った点。
- Why PaaS?
- インフラは PaaS に任せてリソースをアプリ開発に集中する
- Cloud Foundry
- OSS
- エンドユーザ企業や日本企業も Foundation に参加
- マルチベンダで実装。開発スピードが速い
- Structure
- CPI (Cloud Provider Interface) を提供する基盤であればどこでも動く
- BOSH は超すごいオーケストレーションツール
- Cloud Foundary はそれらの上で動く Runtime
- Architecture
- Go で書かれた REST API ラッパの cf コマンドで操作
- cf push するとアプリケーションに応じた runtime をくっつけた droplet になって cell にデプロイされる
- cell では Docker Image も動く
- Service
- データベースなどのバックエンドサービスは環境変数を通じてアタッチする
- HA
- コンテナ/プロセス/VM/AZ の 4 レベルで高可用性を実現
- Cloud Foundry of Pivotal
ベンダロックインされない OSS 版 Heroku という印象ですが、自分で構築/運用するのはなかなか手強そう。大人しくフルマネージドな PCF の導入を検討した方が良さそうです。
WorkShop
@making さん恒例のサバイバルワークショップ。ある程度 Spring Boot を触っておかないと dependency をダウンロードしている間に置いていかれますw
お品書きはこちら。
- Pivotal-Japan/cf-workshop: Cloud Foundry Workshop
- 事前準備 / Prerequisite
- 簡単なアプリケーションをデプロイ / Deploy hello world
- バックエンドサービスの利用 / Use backend service
- スケールアウト / Scale out application
- ログの転送 / Forward logging
- Blue-Greenデプロイ / Blue-Green deployment
- PCF Devを用いたローカルCloud Foundry環境
上記 1. は事前に済ますようあらかじめ連絡があり、当日は時間の関係から 2. から 4. まで実際に手を動かし、5. から 7. までは説明とデモでした。
実際に手を動かした部分では、やはり OSS 版 Heroku という印象。Heroku を使ったことがあれば、すんなり触ることができます。Spring または Play アプリケーションでのみ利用できる Auto Reconfigure という仕組みで Redis 接続先が自動的に切り替わるのが便利でした。
Blue-Green デプロイは、知識として知っているのと実際に目にするのとでは随分印象が違って、これぞクラウドという感じでした。オンプレシステムの移行案件で死んだ経験があったりすると涙なしでは見られないと思います。複数台のサーバがじわじわ移行していく Scaleover も面白かったです。
まとめ
12 Factor App を満たすクラウドネイティブなアプリケーション開発は今後ますます重要になっていくことを再確認しました。最近話題のマイクロサービスアーキテクチャと合わせて少しずつエンタープライズの世界にも浸透してくると思われるので、リードアーキテクト的な立場にいるエンジニアは三回目以降が開催されたら参加されることをおすすめします。
ただ、そんなマイクロでクラウドなアプリをどこで動かすかは状況次第かなと思います。大規模サービスをコア業務としているのであれば PCF を導入するメリットが十分にあると思いますが、小中規模の請負開発ではフィットしない場合もありそうです。
PCF がもっと広まると PWS の東京リージョンができて、そこで運用するという道も見えるかもしれません。少しでも興味を持った方は、まずワークショップに参加して、60 日間の試用期間を使い倒してブログを書きましょう!
象の虫を踏んだ話
大人の事情で古い CDH 5.1.2 を素の設定で使うと Reducer で OOME が出たり出なかったりする。
2016-02-12 00:58:44,134 WARN [main] org.apache.hadoop.mapred.YarnChild: Exception running child : org.apache.hadoop.mapreduce.task.reduce.Shuffle$ShuffleError: error in shuffle in fetcher#1 at org.apache.hadoop.mapreduce.task.reduce.Shuffle.run(Shuffle.java:134) at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:376) at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:167) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1554) at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:162) Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.hadoop.io.BoundedByteArrayOutputStream.<init>(BoundedByteArrayOutputStream.java:56) at org.apache.hadoop.io.BoundedByteArrayOutputStream.<init>(BoundedByteArrayOutputStream.java:46) at org.apache.hadoop.mapreduce.task.reduce.InMemoryMapOutput.<init>(InMemoryMapOutput.java:63) at org.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl.unconditionalReserve(MergeManagerImpl.java:297) at org.apache.hadoop.mapreduce.task.reduce.MergeManagerImpl.reserve(MergeManagerImpl.java:287) at org.apache.hadoop.mapreduce.task.reduce.Fetcher.copyMapOutput(Fetcher.java:411) at org.apache.hadoop.mapreduce.task.reduce.Fetcher.copyFromHost(Fetcher.java:341) at org.apache.hadoop.mapreduce.task.reduce.Fetcher.run(Fetcher.java:165)
OutOfMemoryError: Java heap space
という文字を見て脊髄反射的に Reducer のヒープメモリを増強すると却って傷が広がるので要注意。
事象
MapReduce は以下のようなイメージで動く。象本に載っているのと同じ図がインターネットに転がっていたので拝借。
問題が起こっているのは reduce task
の "Sort" phase
のところ。
mapper が分割したデータのうち、自分が集計するものを集めてマージするわけだけど、mapper が分割したデータは上図のように全部同じ大きさではなくて、あるものは小さいし、あるものは大きい。
そんな状況において限りあるリソースを最大限に活用してできるだけ速くマージするために、小さいデータはメモリに載せて、大きいデータはディスクに吐く。
このうち、ディスクに吐いたデータは当然メモリを使わないので今回の問題には関係なくて、小さいデータが積もりに積もってヒープを食い尽くしてしまったという話。
以下、原因と対応。
原因
結論から先に書くと、CDH 5.1.2 (に同梱されている Apache Hadoop 2.3.0) のデフォルト設定値と実装バグが原因。
設定値
マージに使えるメモリ量 (memoryLimit) は、下記の通りデフォルトでコンテナが使えるメモリの 90% に設定される。
一方で、データをメモリに載せるかディスクに吐くかの閾値 (maxSingleShuffleLimit) は、下記の通りデフォルトで memoryLimit の 25% に設定される。
仮にコンテナのヒープメモリを 1GB に設定した場合、225MB (=1,000 * 0.9 * 0.25) 以下のデータはメモリに載せて、それより大きいとディスクに吐く。
これだけだと小さいデータをどんどん拾ってきた場合に memoryLimit に到達してしまうので、ここにも閾値 (mergeThreshold) が設けられていて、デフォルトで memoryLimit の 90% に設定される。
つまり、メモリでマージするデータ量が 810MB (=1,000 * 0.9 * 0.9) を超えるとディスクに書き出してメモリを解放する。これはスピルレコードとしてレポートに出力されて、チューニングの指標になる。
実装
牧歌的な逐次実行脳で考えると上記の設定で問題ないように思えるけど、現実は甘くないので mapper からデータを拾う処理はマルチスレッドで動いていて、スピルレコードを書き出している最中にもデータがどんどん飛んでくる。
このため、最後の砦としてメモリ使用状況をチェックする処理が入っているんだけど、残念ながらこれがバグっている。
具体的には以下の箇所で、
if (usedMemory > memoryLimit) {
現状のメモリ使用量だけではなく、これから扱おうとしているデータ量も考慮して
if (usedMemory + requestedSize > memoryLimit) {
と判定しなければならない。
これができていないので、例えば
- コンテナのヒープメモリが 1GB
- すでにマージ用メモリに 890MB 載っている
- スピルレコードの書き出しは終わっていない
という状態で、mapper から 200MB のデータを拾ってきたとすると、上記チェック処理は
- メモリ使用量は memoryLimit に到達していない
- 200MB は maxSingleShuffleLimit より小さい
と判定してデータをメモリに載せようとするので、メモリ使用量は 1090MB (=890 + 200) となり、ヒープメモリを食い尽くして Reducer が死亡する。
対応
実装はまだ直っていない。2.8.0 で直るらしい。
自分で実装を直してビルドするような豪傑でない場合は設定値をいじって対応する。最新の Hadoop では memoryLimit のデフォルト値が 70% に変更されているので、これに倣えばよい。
2016/04/20 修正
CDH 5.1.2 では設定ファイルで memoryLimit のデフォルト値を 70% に設定していた。Mapper の数に対して Reducer が少な過ぎたためにスピルレコードの書き出しが間に合わなかったと考えて、Reducer 数を増強した。Reducer 数は Mapper の総出力ファイルサイズをブロックサイズで割って算出すればい。
まとめ
以上のとおり、処理タイミングに依存した問題だったため再現性が低くて苦戦したが、原因が分かってすっきりした。
それから、(たぶんヒープサイズの問題ではないとぼくが止めるのも聞かずに) 脊髄反射的にヒープメモリを増強したら、これまではディスクでマージしていたサイズのデータもメモリに載るようになり、却って再現性が高まってウケた。
当たり前だけど、問題は論理的に原因を切り分けて対処しましょうと再認識。システム開発にオカルトは存在しない。
参考
- 作者: Tom White,Sky株式会社玉川竜司,兼田聖士
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/07/26
- メディア: 大型本
- この商品を含むブログ (4件) を見る