Recommended
More Related Content
What's hot
What's hot (20)
Similar to Hatena::Letの式年遷宮
Similar to Hatena::Letの式年遷宮 (20)
More from Takafumi ONAKA
More from Takafumi ONAKA (20)
Recently uploaded
Recently uploaded (9)
Hatena::Letの式年遷宮
- 1. Hatena::Letの式年遷宮 2021-11-25 Hatena Engineer Seminar #17 大仲 能史 a.k.a. id:onk
- 2. 自己紹介 • 大仲 能史 a.k.a. id:onk • 株式会社はてな チーフエンジニア • ノベルチーム所属 • チームではWebアプリケーションエンジニア、 技術グループ全体ではマネージャ業をやっています
- 3. 今日の話
- 4. 式年遷宮
- 5. 式年遷宮とは • 伊勢神宮では、20年に一度、社殿と神宝を新調して大御神にお遷り 願う • 土地が2倍用意されていて、20年おきに隣に建てて移す • 社殿や御神宝を、変わることなく継承し続ける祭祀 • 建物そのものがレガシー (オリンピックで聞いた方) なのではなく、 維持する体制を維持する
- 7. ソフトウェア式年遷宮とは • 2013年にid:kenjiskywalkerによって提唱された概念 • 2013年 • 伊勢神宮＆出雲大社の式年遷宮の年 • インフラのB/Gデプロイメントを 式年遷宮に見立てた https://blog.kenjiskywalker.org/2013/08/11/shikinen-sengoo-infrastracture/
- 8. ソフトウェア式年遷宮とは • 2014-2016年に一般に広まる • id:antipop • JAWS DAYS 2014 Immutable Infrastructureトラックのパネルディスカッション • id:ryotarai • クックパッドのサーバプロビジョニング事情 - クックパッド開発者ブログ • id:mirakui • クックパッドの継続的な成長のために開発と運用が何をしてきたのか、その失敗と 成功について - Speaker Deck
- 9. ソフトウェア式年遷宮とは • 2018年 id:edvakfによる拡大解釈 • 放置しがちな社内システムこそ式年遷宮していこう - pixiv inside • インフラだけじゃなくソフトウェアも式年遷宮する • 定期的に作り直すことで、メンテナビリティが向上し、新規開発 からの学びも得られる
- 10. ソフトウェア式年遷宮とは • 2020年 id:daiksyにより更に意味が加えられる • プロダクトを10年運用する チームをつくる / DevSumi2020 - Speaker Deck • 全てをフルスクラッチで作り直す前に、周期的に手を入れ続ける • プロダクトを構成する要素単位で作り直すことでブラックボックスや 負債になりかけた要素をモダンにし、エンジニアの技術継承を行う • 作り直した後、遷宮参加者はその要素に一番詳しい状態になる
- 11. 今日の話 • ソフトウェア式年遷宮とは • Hatena::Letの歴史 • 遷宮のリアル • まとめ
- 13. Hatena::Letの歴史 • 2009-11-07 • サービス開発合宿でid:secondlifeとid:cho45が開発 • 余談：同じ開発合宿で作られたのがHatena::Haiku • 2010-05-15 • ラボサービスとして公開
- 14. Hatena::Letの歴史 • 2010-07 • id:secondlife退職 • 2011-12 • id:cho45退職 • id:sampleが引き継ぐ • 2017-10 • id:sample退職 • 有志のオーナー不在に • SPFチームがオーナーとしてメ ンテナンス ※公開情報が見つからないので仮名。
- 15. Hatena::Letの歴史 • 2018-04 • id:onk入社 • 2018-08 • オーナー引き継ぎ • 引き続きメンテナンスモード • 2020-05 • さようならPerl、こんにちはRuby
- 16. 遷宮した
- 17. 遷宮という選択に至るまで • リリース当時 (2009) の技術 • はてラボサーバ • はてながAWSを使い出したのは2011年 • はてラボDB • 共通DBモデル • Hatenaフレームワーク (Perl) • Ridge + MoCo • ざっくり言うとRails 1.5ぐらいに相当
- 18. 遷宮という選択に至るまで • 2009年に作られたまま、細々とメンテナンスされている • EC2移転や共通DB脱出は行われた • DBのスキーマはベストではない • Ridge+MoCoのままメンテナンスするのはコストが高い • Ridge: last commit 2013-01-10 • MoCo: last commit 2012-04-10 • 失われた技術スタック
- 19. サービスを作るときの軸 • サービスを作るときは以下の 2 軸で考えることが多い。 届ける速度と、ユーザに価値があるかどうか https://www.slideshare.net/takafumionaka/25-137790052
- 20. サービスを作るときの軸 • 第 1 象限は「やる」 • 第 3 象限は「やらない」 • 第 4 象限は「誘惑」 • すぐできるけど、そんなに価値はない • 他の優先課題があるかもしれない • 壺に石→砂→水を詰めるってコピペがあるよね？ https://www.slideshare.net/takafumionaka/25-137790052
- 21. サービスを作るときの軸 • 第 2 象限を一番考えなきゃいけなくて、 価値があるからぜひ作りたい。けど作るの が難しい機能 • これを実現するのがプログラマとしての腕の 見せ所になる https://www.slideshare.net/takafumionaka/25-137790052
- 22. サービスを作るときの軸 • フレームワークは「価値があることをすぐ作 れるようにする」のが役目 • 第 2 象限を第 1 象限に変える • もしくは第 4 象限を魅力的品質まで高める ことで第 1 象限に変える • そこに寄与しないなら不要 https://www.slideshare.net/takafumionaka/25-137790052
- 23. 遷宮という選択に至るまで • 全てを掌握して、メンテしていきたい • 特にDBリファクタリングをしたい • 今のフレームワークは価値に寄与していない • 簡単にDBを変更できるか？ => 現在においてはNo • 魅力的品質を生んでいるか？ => 現在においてはNo
- 24. 遷宮用の技術選定 • インフラはノータッチ • Sinatra + ActiveRecord • ERB • static fi lesはノータッチ
- 25. やったこと • MoCo => ActiveRecordに変換 • 10テーブル程度だったので、気合い • そこそこARの中を知ってないと難しかったと思う • PKが無いテーブルを、PK必須なORMで扱う • ナチュラルキーPKな関連テーブルを、サロゲートキーを期待す るORMで扱う
- 26. やったこと • ActiveRecord投入は僕の常套手段 • 他のリポジトリでもやっている • メンテ用のREPLやORMが欲しい • データを理解するための最短手段 => 空でER図が書けるようになるまで写経する • 学問に王道なし https://developer.hatenasta ff .com/entry/2018/11/21/120000
- 27. やったこと • Ridge => Sinatraに変換 • RESTfulではないURLが使われているが全て維持した • 掌握が先、変更は後 • 久々に sinatra app を作った - id:onk のはてなブログ
- 28. やったこと • Xslate => ERBに変換 • 20ファイル程度だったので、そこまで手間じゃない • XslateからERBならそのまま翻訳できる • ここが簡単であって欲しいのでサーバ側でHTMLをレンダリング する手段を選んだ
- 30. 全部読むと分かった面白ポイント • 「;」区切りのクエリパラメータが存在している • https://onk.hatenablog.jp/entry/2020/12/18/202554 • Validではあるが、実際URL Escapeしてしまうクローラが存在し ていた • I18n対応していた • メニューやボタンの文言が英語に
- 31. 全部読むと分かった面白ポイント • IE6SP2対応 • URL長の制限がキツい(488文字)ため、minifyしても `javascript:(function(){...})()` 形式だと、よくあふれる • 一定長以上だとscriptタグを挿入するブックマークレットになる仕 組みになっている • Mixed contentsやContent Security Policyの影響を受ける
- 32. 数値で見る遷宮 • $ git show xxx ̶stats • Hello, Ruby! • 55 fi les changed, 2827 insertions(+), 32 deletions(-) • Bye Perl • 111 fi les changed, 10478 deletions(-) • だいたい 1/3 ぐらいのコード量に
- 33. 遷宮後にやったこと • ActiveRecordで良かった！ • ignore_columnsやcallbackを駆使して、本番DBリファクタリングを 実現可能だった • レールから外れたデータベースを扱う - onk.ninja • 主キーが無いテーブルや複合主キーはサロゲートキーを追加する • timestampsを見慣れたxxx_atにリネーム • ナチュラルキーを倒したり、テーブルごと作り直したりも
- 34. 遷宮後にやったこと • URLをリソース志向にシフト • POST時にクエリパラメータとBodyが両方あったらどう扱われる のか、みたいな悩みどころがあった。ので減らした • ForkはGETではなくPOSTを使う • クローラがGETリンクを見つけて、クリックしていた • 毎日2000回ぐらい、クローラが(リダイレクトされて)ログイン 画面を表示して、諦めていた
- 35. 遷宮後にやったこと • インフラをマネージド化 • Perl時はEC2 + EC2(MySQL) • 今はALB + ECS + Aurora + ElastiCache(Redis)
- 36. 遷宮後にやったこと • JSのminifyにはterserを使うように移行 • もともとの仕組み (JavaScript::Squish) だと、ES2015以降の書 き方をしたときに、例えばテンプレートリテラルが途中で消える 等の問題があった
- 37. コミュニケーションの喜び • ユーザさんは問い合わせせずに、サービス上で不具合の動作確認を してくれる • 再現する最小コードを投稿してくれるの凄すぎる • TOPページを眺めていたら見つけた
- 40. 今後の展開 • Greasemonkeyにどこまで近づくか • 例えばGreasy Forkという競合サービスがある • インストール数とかを取得できるようになると公開する楽しさが 増える • 検索したいって声にも上手に対応したい
- 41. 今後の展開 • graphql-rubyを導入してフロントエンド刷新 • DB改善が終わったので、すごく扱いやすくなった • Rubyなのはそのままでも良いかなぁ • Hatena::Letを作ったid:secondlifeも、はてなでRubyを使い続 けていた人なので、意志を継いでいく（？） • Perl の会社で使われる Ruby の利用法とは!? - 日本Rubyカン ファレンス2006
- 42. 今後の展開 • インフラ構成で遊ぶ • 現在はALB + ECS + Aurora + ElastiCache(Redis) • こうしてみる？ • CloudFront + API Gateway + Cloud Map + ECS + Aurora + DynamoDB • CloudFront + API Gateway + Lambda + Aurora + DynamoDB • 300req/min未満ならAPI GatewayはALBよりお得 • コストが低くなると持続可能性が高まる • ちょっと面白い構成はどんどん試しておきたい
- 43. 社の標準スタックの一歩隣を行く • 正しいラボサービスの姿 • 最近のはてなの標準技術スタックは gqlgen + Next.js • 似ているが少し違う技術を使うことで、知識の幅を広げる • これは僕が18年選手＆Hatena::Letがアプリケーションとして小さいから 選ぶ方法 • 慣れていないor複雑な要件があるなら、同じ技術を複数アプリケーショ ンで使う方が予想外の要件で荒波に揉まれることになり、深みが出る
- 45. 「式年」遷宮の必要はあるか • ヨシヨシできていれば問題無い、という話はある • Webサービスはヨシヨシしないとスネる - pblog • そこそこヨシヨシしていてもスネる（＝負債は溜まっていく） • 業務ですら全ての行に目を入れ続けるのは不可能で、知識が欠けていく • 運営チームがドメイン知識を再獲得するための遷宮 • やる範囲を見極めつつ、コア機能こそ式年遷宮する必要があるのだろう • 列車を走らせ続けながらパーツを交換するイメージ