JTF2015参加レポート
まえおき
今年もJTFに参加してきた。
去年はJuly Tech Festaといいつつ6月だった気がする。
個人的には、開催時期は6月のほうがうれしい。
7月後半は子供たちが夏休みということもあり、6月に比べて世間で他にもいろいろ魅力的なイベントがやっているので。
まぁまた来年もやるなら7月でも行きますが。
簡単にレポートを書く。
ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから(@horiuchi)
資料
感想
- 「AWSの堀内さん」しか知らなかったので、堀内さんのこれまでの経験を踏まえて、これからのエンジニア像を語ってくれた本セッションは面白かった。
- 堀内さんがAWSのエバンジェリトだった頃、AWSの新サービスが登場する度にそのサービスの概要やメリットを分かり易くユーザ伝えている堀内さんを見て、何故こんなに幅広い分野のサービスを理解できるのだろう、と不思議に思っていた。
この発表を聞いて、それを可能にしていたのは、ベンチャーCTO時代に様々な技術に触れた経験が大きかったんだろうな、と思った。 - なので、最後にスタートアップCTOがお薦め、という話が出てきた時、それまでの話の流れからガラっと変わった印象を持ちつつ、妙に納得した。
マイクロサービスで、一歩先行くImmutable Infraを目指そう(@sho7650)
資料
ざっくり要約
稼動したシステムには変更を行わない"Immutable Infrastructure"という考え方が出てきた。
mmutable Infrastructureを実現するときは、ステートレスなサーバ(Web, App)とステートフルなサーバ(DB)でやり方を変えよう、というのが今の流れ。
上記のようなシンプルな図を眺めている分にはそれで良さそうに思えるが、実際にImmutable Infrastructure実現しようとしたら、話はそう単純ではない。
エンプラなシステムなどは接続先がたくさんある。あるサーバ切り替えて周りのサーバが落ちる可能性がある。これは課題。
この課題の解決策としてマイクロサービスが出てきた。
マイクロサービスのポイント
コンポーネント化する。
コンポーネント化とは、インタフェイスを明確にすること。ロジックに変更があってはいけない。
- メモリをコンポーネントと考えると、速くなった、容量が大きくなったはOK。機能が削減されて、今まで通ってたロジックが通らなくなったはNG。
上図ではブルーとグリーンでインタフェイスが変わってなければ、どんな複雑はシステムでも、ブルーグリーンデプロイメントできる。
作ったプログラムはプロジェクトとして扱うのではなく、プロダクトとして扱える。
- プロジェクトとして扱うと、始まりと終わりができる。そうではなく、プロダクトとして捉え、開発者が最初から最後までやる。
- 同期はREST, 非同期はMQなどシンプルな構造にする。
最近のマイクロサービスの文脈では、「どうやって？」という部分の話はあまり出てきていない。
そこは、これからみんなの知見が集まっていかないと話ができない部分。
=> SOAの知見が役に立つのでは？
SOA
- マイクロサービスでcomponentといっているものを、SOAだとサービスと言っている。サービスは一番小さな単位。
- サービスの規約は何でもいいと言っている。REST、MQなど手段具体的な実装方法については言及していない。
- だから、SOAはマイクロサービスに比べると、自由度が高い。
- プログラムの考えで言うと、構造体→オブジェクト指向→SOAという流れ。
- Service Repository。サービスを登録しておくところ。サービスのHUBみたいな。
マイクロサービス vs SOA
SOA ロードマップ
- 基礎段階: 保守性の向上
- ネットワーク化段階: カプセル化。中継層に担わせる。中継層･･･技術的に難しいことを担わせる。
プロセス制御段階: 俊敏性の向上。
- SOAのプロセス制御は、普通のセッションより長くセッションを保とうとする。普通ログアウトしたらセッションは切るが、SOAだとログアウトした後も保とうとする。
まとめ
- 新しいものと古いものを組み合わせて使う。
- 車輪の再開発はしない。
- Re-usable not Re-cycle
- もともと再利用可能しておいてそれを使うのと、あるから使うというのは全然違う。後者は辛くなる。
感想
去年会社の勉強会でマイクロサービスって考え方が流行りつつあるらしい、という話をしたら、「それSOAと何が違うの？」と言われて、SOAを知らなかった自分は「？？？」となった。
RebuildでもマイクロサービスとSOAについて言及してた気がするけど、「SOAはエンプラ臭がする」とかそんな程度の話だった気がする。
そんな感じでマイクロサービスとSOAについてはかなりもやっとした理解しかなかったのだけど、この発表を聞いて、マイクロサービスとSOAの違い、何故マイクロサービスの文脈でSOAを出す必要があるのか、といったあたりを理解することができた。参加してよかった。
MONITORING DOCKER(@jhotta)
資料
なし
ざっくり概要
- datadogで働いている。
- datadogのblogで、監視についての連載を始めた。Monitoring 101: Collecting the right data
- monitoringをDIYしていると、機能追加なんてできない。
- monitoringツールを作ることが、競合との差別化に繋がるのか？というところは考えて欲しい。
- Docker監視で「コレだ！」というのはまだない。
- WHY DOCKER USERS MONITOR
- ステータスみたい
- Docker Engineが壊れているの？特定のコンテナ？それとも周辺ツール？というのが知りたい。
- タグや正規表現によってグループ化できる監視ツールでないと、コンテナの監視は辛い。
- dockerのメトリクス取れる場所(後者２つは正しくない。）
- cgroups
- docker api
- in-container agent direct monitoring
- kernel hacking
- NewReric - eventとmetricsを紐付ける機能が弱い。
- SYSDIG･･･カーネルハッキングしている。
- SIGNALFX･･･今後注目。メトリクスの関連性の取り方とかいい。後発で、勉強してきたイメージ。 メトリクスの測り方は他と違う。
- LIBRATO･･･fluentd
- PROMETHEUS
感想
- コンテナの監視を設計する日が来たらとりあえずdatadogのblogを読んでみようと思った。
最前線で戦う若手インフラエンジニアたちが語る「技術トレンド」と「数年後の未来」(@y_uuk1, @catatsuy, @hfm, @deeeet, @rrreeeyyy)
資料
概要
- ブロッコリーのブログによくまとまっている。
感想
- プロビジョニングツールの話のところで、サーバ設定の"設計の難しさ"とプロビジョニングツール自身の扱いの難しさが混同されることが多いから、そこは話解き分けたほうがいいという話があって、それは確かに気をつけたほうがいいと思った。
- プロビジョニングツールやコンテナなど技術的な話も参考になったが、それよりもチームとして成果を出すためにどんな取り組みをしているかという話が参考になった。特に@hfmさんの研修の話やチームメンバのアウトプットが共有される仕組みづくりの話など。
運用に自動化を求めるのは間違っているだろうか(@zembutsu)
資料
概要
資料を読めばOK。
感想
発表中に出てきた次の2つの考え方がすごくしっくりきた。
- 働いたら負けでござる。刺身タンポポ業や写経文化の中で働いたら負けでござる。
- DockerやHashiCorpのプロダクトが流行っているが、一つのツールが全ての課題を解決できる銀の弾丸になるはずはない。
なのでそれらを手札と捉えて、使えるツールを増やしていき、最強のカードデッキを作るようなイメージを持つ。
おわりに
- 今年もいろいろな話が聞けて楽しかった。来年の参加したい。
- 電源が欲しい、電源が欲しい、電源が欲しい。
- 休憩時間にやっているスポンサーのハイアリングセッションが面白かった。
