Weitere ähnliche Inhalte Ähnlich wie 企業を超えたアジャイル+Railsを利用した開発の成功事例【WESEEK Tech Conf #8】 (20) Mehr von WESEEKWESEEK (16) Kürzlich hochgeladen (20) 18. JPNAP
● IXP → 超巨大なL2ネットワーク
● 東京、大阪、福岡、仙台に展開
● 総※トラフィック 3.88Tbps
● 総※AS数 200以上
18
※4つのIXの合計値
接続されているネットワークの一覧は公式HPへ
『JPNAP お客様一覧」で検索🔍
19. JPNAPにおける自動化のあらまし
2014年〜2015年頃の動き
● 社内の一部の人で開通作業の部分的な自動化・ソフトウェア開発が始まる
○ cf. 「JPNAPのソフトウェア化事情」川上雄也 JANOG34@高松 2014-07-18
https://www.janog.gr.jp/meeting/janog34/doc/janog34-sfeng-kawakami-2.pdf
○ cf. 「インターネットエクスチェンジで運用自動化にStackStormを導入した話」杉本周
StackStorm Meetup JP #10 2021-04-23 / StackStorm勉強会 第2回 2017-03-23
https://www.youtube.com/watch?v=4EnC-Ehc31I&t=2632s
● 世界最大級のIXが開通の完全自動化を実現していることを知り衝撃を受ける
○ cf. “IXP update” APIX#11(APRICOT2015)@福岡 2015-03-01
※資料非公開
● 『JPNAPでもここまでやれるはずだ』『チーム開発は必須…どうすれば？』
→ 社外リソースを活用したハイブリッドな開発チームの立ち上げへ
19
21. WESEEK との関係
● WESEEK はインフラ～アプリのフロントエンド開発までワンストップで提供
できる
● 社内の様々な問題の解決・改善のために弊社 武井へ相談
○ 内製開発だけでは解決できない課題があった(後ほど)
● 2015年 WESEEKとの共同プロジェクトを開始
○ そこから 6 年以上経て、現在へ
21
24. 社内ツール事情(2/2)
● 起きていた問題
● ex.) ツール作成者がいなくなったあと、誰も保守できない
○ ○○まではできるけど、これに△△を追加したい
○ どこをどう改修したらよいのか…
○ 1 からソースを読もうとするが時間がない
● ex.) 本業の傍らで、なかなかやりたいことを開発できない
○ 本業は IX ネットワークの構築、保守
○ なかなか未来を考える時間が取れない…
24
28. 初期フェーズでやったこと(1/3)
● 技術選定
○ 継続的な開発・メンテを実現するために、利用技術は統一化した
■ バックエンドについては Ruby on Rails を採用
● 既に Ruby で書かれたツールが他に存在していて、一番低コストで開発・保
守できるから(MF からの要望)
● Rails は Ruby での MVC フレームワークのデファクトである
○ ORM から始まり task runner(rake) まで、業務のロジックを実装す
るための仕組みが一通り揃っている
○ コミュニティによってちゃんとメンテされている
○ フロントエンドについてはあとで、AngularJS を追加で採用した
28
継続的なチーム開発/メンテの実現
29. 初期フェーズでやったこと(2/3)
● WESEEK でそれまで行ってきた開発フローを MF 社に導入
○ 2015年当時やったことなので、ここに載っているツールは古いです…
● 開発/フィードバックをやり取りするためのツールを導入
○ Slack
■ 導入当初、MF 社内では HipChat を利用中だった
○ Redmine
■ Backlog plugin を利用し、出てきた課題をストーリーとして作成
■ 約 2 週間のスプリントごとに消化
○ GitHub
○ Jenkins
■ CI/CD/cron
29
継続的なチーム開発/メンテの実現
32. 今までの開発してきたプロダクト一覧
● esthar (Angular)/dollet (Rails)
● centra (Angular)/nautilus (Rails)
● starrod (Ruby)
● server-config-generator (Ruby)
● 開発実績 (nautilus)
○ 26,703 コミット (2016/3/8~), PR 数は 4400 以上
○ モデル数: 103
○ テスト数: 3114
○ リファクタも何度となく経験
32
継続的なチーム開発/メンテの実現
37. スケール/ボトルネック解消へ(2/2)
● WESEEK 人員が MF 社内 MTG に参加
○ 本業で困っていること、改善したい箇所などを WESEEK メンバーが直接ヒアリングで
きる状態へ
● Slack 上にフィードバックを行えるチャンネルを用意
○ MF 社内で業務中に困ったことをすぐにアウトプットできる場所を準備した
37
開発のボトルネック解消
開発規模のスケールアウトの実現
41. 開発/リリースフロー(1/3)
● git + Jenkins Multibranch Pipeline
○ トピックブランチを push すると、CI が回りだす
■ 構築当初は出来る限りクラウドに出したくなかったので、社内に Jenkins を立て
ることに
■ 今は社内利用サービスのクラウド化などが進み、敷居は当時より低くなっている
● ex.) GitHub Actions
41
CI の整備
42. 開発/リリースフロー(2/3)
● CI 時に行われていること
a. erd gem による ER 図出力
b. rubocop gem による lint
c. rspec gem によるテスト
■ テスト量が多いため、rspec-queue を利用し 3 並列で spec を回している
d. OpenAPI YAML -> HTML への出力(redoc)
42
CI の整備
43. 開発/リリースフロー(3/3)
● git ブランチポリシー
○ master: 開発版最新
○ stable: リリース版最新
○ その他 Redmine のかんばん上のタスクごとに、トピックブランチを作る
● master へのマージで、lab/staging 環境へ反映
○ デプロイ先環境上で、各種動作確認などを行う
● stable へのマージで、本番環境へ反映
○ master ブランチを stable ブランチへマージする Pull Request を作り、マージするだ
け
43
CD の整備
45. デプロイ先環境(2/3)
● lab
○ master ブランチのバージョンが動いている
○ 検証環境のデータが入っている
● staging
○ master ブランチのバージョンを動かしている
○ production 環境のデータが入っている
■ 毎日 2 回、production 環境からのデータ同期を行っている
○ 本番データを利用している理由
■ 検証環境のデータでは、モデルの量とモデルの構成パターンが足りていない
■ 本番環境にあるデータで動けば何も問題ない、という考えのもとに生まれた環境
■ master ブランチのバージョンで動かした際に出てきた事象の検証、リリース前の
動作確認などで使われる
45
CD の整備
本番データのみで起きるバグへの対応
47. 利用 gem の選択基準
● メンテされているかどうか、今後メンテされるかどうか
○ メンテされていないと、Ruby/Rails のバージョンアップの足かせとなる可能性が出て
くる
○ ex.) https://github.com/hzamani/active_record-acts_as
■ ActiveRecord の polymorphic association で MTI(Multi-Table Inheritence)
を実現するための gem
■ そこまで active に開発されておらず、Rails update 時の足かせとなった
○ メンテの判断基準として、GitHub star 数や直近のコミット日時なども参考になる
■ GitHub star 数が多い = 利用者が多そう
■ コミット日時が直近 = メンテされていそう
47
技術的負債化の回避
49. 利用 gem ご紹介
● 開発補助系
○ Airbrake (例外通知)
○ erd (ER 図出力)
○ tachikoma -> Dependabot (アップデート自動化)
○ rubocop (コーディングルール統一)
○ guard-rspec (テスト実装高速化)
○ bullet (N+1 問題に気づけるように)
○ active_record_query_trace (発行された SQL に関する stacktrace 出力)
● 機能系
○ jbuilder (JSON template 部品化)
○ activeadmin (CRUD 画面作成省力化)
○ devise + cancancan (認証・認可実装の省力化)
49
デプロイ後のエラー発見
開発の高速化
51. My.JPNAP 公開へ
● 新・MF 顧客向けポータル
○ nautilus といくつかのプロダクトがバックエンドとなっている
● プロダクト構成
○ centra (Angular)
■ My.JPNAP フロントエンド
○ nautilus (Rails API)
○ gargant (Rails API)
■ IX ネットワーク上で稼働している機器のステータスを返す
○ suppon (Rails API)
■ JPNAP をご利用中のお客様へのお知らせ情報を返す
○ nautilus がモノリス化していたため、My.JPNAP に必要な機能の内、ある程度の役割
ごとにプロダクトを分割して構成した
51
53. 技術的負債への対応
- SRE という概念が 2017 年から出てきた
- サイト全体を面倒見る人の総称
- ソフトウェア～インフラまで幅広い知識が必要となる
- 運用はできる限りエンジニアリングで解決する
- 新しいものを追いかけていないと実現できない
- 本案件でも様々な変更を行ってきた
- tachikoma -> Dependabot
- Jenkins -> GitHub Actions 使えるところは使う
- AngularJS -> Angular -> Vue/React …
- 開発環境 Vagrant -> devcontainer
- インフラ オンプレ -> Kubernetes
- etc...
53
54. まとめ
● 当たり前のことを当たり前にやる大切さ
○ WESEEK 内で確立されていた高い「当たり前品質」を MF 社内に根付かせた
● 機動力・柔軟性
○ アジャイルの強み ＞ 日本企業的契約形態に引っ張られる硬直
○ MFの文化受容に対する柔軟性、「正しいこと」に対する理解
● Rails の強み
○ コミュニティによりメンテされている豊富な機能を利用して開発できた
54
56. 利用 gem ご紹介(開発補助系1/3)
● Airbrake
○ 例外通知管理アプリ
○ 各環境上のアプリケーションで起きた例外を Slack へ通知させている
■ コントローラの基底クラスに rescue_from を書いておき、notify するコードを
仕込む
○ Airbrake.io 上でどの程度同じ例外が出ているのか、デプロイで fix されたのか確認で
きる
○ 各環境で出た例外が Slack から一目でわかる
■ stacktrace, アクセスされた URL も関連付けて表示される
■ リリース後に発生したバグ対応などが迅速に行える
56
エラー対応の迅速化
57. 利用 gem ご紹介(開発補助系2/3)
● erd
○ モデルファイル/schema.rb から ER 図を PDF に出力してくれるツール
○ 既存モデルの全体像、関係性を一目で把握できる
● rubocop
○ 言わずと知れた Ruby コード用の lint ツール
■ ただ、中には行き過ぎたルールもあるので、都度調整
■ Style/AsciiComments は日本人にはツラい
● tachikoma -> Dependabot
○ Gemfile に記載のある gem で update が存在した場合、Git ブランチを切って
bundle update してくれる
○ gem 自体メンテがストップしているのと、GitHub が Dependabot を始めたため既に
乗り換えている
57
開発の迅速化
58. 利用 gem ご紹介(開発補助系3/3)
● guard-rspec
○ guard というコマンドを打ち、待機状態にしておく
○ その状態でテストコード、またはテスト対象コードに変更が加わると、テストが自動で
走ってくれる
○ テストコードを実装しているときに重宝する
● bullet
○ SQL N+1 問題が発生しているクエリをログに吐いてくれる
● active_record_query_trace
○ Rails 標準で出力される SQL 実行ログに、どのコードで実行された SQL か trace を吐
いてくれる
58
開発の迅速化
59. 利用 gem ご紹介(機能系)
● jbuilder
○ erb template のように JSON を書けるテンプレートエンジン
■ partial render 等を利用し、テンプレートの共通化が可能
○ rails で API server を開発する場合には必須
● activeadmin
○ モデルを用意し、コードを書かずに CRUD 画面を用意できる
■ 簡単な DSL を書いたファイルを用意すればおわりです
● devise + cancancan
○ Rails に認証・認可機能を統合するときの定番
○ アプリケーションへのログイン処理で利用中
59
開発の迅速化
