途中で疲れたので全般的に雑です…
なぜSearsar止めたのか
ひがさん
当時はAKBで例えるとヘビロテが流行ってたくらい
技術の面では既存のエリアに居続けてもある程度行ったら伸びなくなる。
心地は良いけど。
Enterprise Javaはやりきった感
みんなSeasar2から卒業しよう
あと1年で開発打ち切り。
2016/9/26を持って打ち切り。
今まではユーザーのためにやってた。
Seasar2のコミッター小林さんに超感謝。
ひがさんがアウトプット止めた理由は？
2011年4月くらいから電通にで仕事してた
基本発表できないからめんどくさいからアウトプット自体やめた
なんで今更Seasar Conferenceやることになったの？
橋本さんより
飲んでるときにやりたいねってなって盛り上がってやった
自分のアイデアありき、ではなく、他の人がほしいものは何か、自分もほしいものは何かを考える
アウトプットするだけじゃダメ。
使ってもらわないと。
ISIDとSeasar2の関係
Seasar2はビジネスではない
普及の役に立つから。
ビジネス的に成り立たせようとすると有償サポートだけじゃ足りなくて有償セミナーとかバンバンやらないと成り立たん。
サポート大変。
【世界最大】クックパッドの microservices 化【WIP】 – 庄司嘉織
Microservicesの話
ファウラーは言いました。
「ほとんどのシステムは単一のモノリシックアプリケーションとして構築されるべきです。」
最初からやるべきじゃない。
複雑さがましていってどうしようもなくなったら分けろ。
世界最大級のモノリシックRailsアプリケーション
https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-largest-rails-monolith
モノリシックでもいけてるのに本当にお前ら必要なのか？
でかいものを切り分けた知見を紹介
どうやって切り分けるか？
- 縦に切るか
- ビジネス領域によって切り分ける
- 基本はこれ
- 横に切るか
- 機能で切り分ける
- 特定の領域に特化したEverything as a Service的なもの
切り分けるときに自分でどっちを切っているのか意識した方がいい。
混乱しちゃう。
共通言語
Garage
Cookpadのサーバー間通信は全てこれを使ってHTTPでやりとりしてる
Everything as a Service
縦に切るより簡単
他からも使えることを意識して考える
デプロイ・開発環境もシンプルに保てる
Netflixとかはレコメンドが落ちててもその部分が表示されないだけ
- Cookpadだけで個別に欲しい機能がある場合は？
- 新しいエンドポイント生やさなくてもオプションとして追加されても他サービスとしては困らない
- 落としたくないから余計な庫とするな→落とさない！
- 横と縦の判断はどうするのか
- 答えになんないかもしれないけどセンス
- 経験から来る物はやっぱり大きい
- DDDに結びつけてくってのが最近よくでるけど
- DDDは1回忘れた
- 遅くなるんじゃないか
- キレイにやり過ぎると開発速度が落ちてしまうのではないか
まだやってる最中だから正しい答えは持っていない
縦に切る
概念的にはこっちの方がわかりやすいけど、大変だった
- ドメインとクッキーの問題
- 同一ドメインにするか
- サブドメイン
- 完全別ドメイン←最終的にこれ
- 全部やった
ログインシステム5回作った
完全同一ドメイン
クッキーが完全に共通になる→セッションが維持されずに破綻する
アセット周りの管理がクソめんどくさくなる
→ やめた
苦労するけど利点がない。
利点は一個だけ、クロスドメインの問題は発生しない。
サブドメイン
クッキー一部共有
完全別ドメイン
クッキーは完全別
ログインの引き継ぎできないからユーザーにボタン押してもらった
一番いいと思うのはサブドメイン
サブドメインだとSEO的に不利。
完全別ドメインだとSEO的には有利。
そこらへんを天秤にかける。
キャッシュ戦略
APIのエンドポイントはシンプルにする
複数問合せに対応すると…
20コ問い合わせて18コだったらどうするのかを考えないといけない
処理が複雑になっていく
MSAで多段になってくるから非常に複雑になる
今のところは…
Varnishでキャッシュしてる（アプリに行く前に返す）
単一リソースAPIをMemcachedに入れる
考える余地はある
- HTTPのコネクションコストが高いからHTTP/2にすることとか考えてる
- 非同期にするとか
他に社内でライブラリ化したもの
- PCとかのログ収集
- カスタムなすうち取得システム
- ログイン周り
- ヘッダフッタパーツ
- 広告
- デプロイ周り
- Docker使ってるけどアセットがめんどい
- CDNとかつかったりして
- CI周り
- Jenkinsカスタマイズして使ってる
- 通知とか
- エラー集計
- エラー発生した時にすぐ
- Sentryが立ち上がってやってる
実際に切り分けてみて
やってよかった！
ドラスティックなチャレンジができるようになった
エラー管理が自分たちで管理できるようになったから自動でIssues切ってアサインしてくれたりできる
Cookpadは社外の人間にどれだけ貢献したかが社内の評価に繋がってる
- MSAでやりたかったことは？
- 動画周りがCookpadにくっついてるとやっぱり遅くなって辛い
- 事業的な都合
- 個人的にいつまであのままなのか？という思い
- 合意を得にくいのでは？
- 得にくいです
- 非エンジニアからするとどうでもいい
- インフラコストかかるようになるし
- なんでそんなことすんの？
- エンジニアとして同じ事やってるの飽きるじゃん
俺は守りに入らない、これが今の俺だ – DJ Yasuo
国際的なことを考えてDJ Yasuo
ガチにDJを目指して学校3つ通ってる
ダンス作るためのハードウェアを作る→DJになる
Go
Goとは
- 静的型付けコンパイル言語
- Cに近くLLではない、けどサクサク作れる
- 継承なし
- ジェネリクスなし
- けっこう満足している
JavaからGoへ
実行がLLっぽい。
javacみたいなのしなくていい
コンパイルと実行が同時に実行できる
- Java:Classpath
- Go:GOPATH
- go get でライブラリをすぐに取れる
開発はGOPATH配下に持ってきて開発するのがベスト。
ライブラリの依存関係はソースコードだけでいけるのでいい感じ。
アクセス指定子
- Java：private = Go：全部小文字
- Java:public = Go:先頭大文字
インターフェース
キャスト
例外
if err != nil
だらけになる
最終的にこれに慣れた