Download to read offline
Rakus MeetUp 正攻法はあるのか!?泥臭く戦ったNode.jsバージョンアップ一部始終
- 1.
- 2. 自己紹介 名前：西原 優人（ニシハラ マサト） 所属：株式会社ラクス 経歴： 年入社（ 年目） ・の開発にて を用いた開発を経験（ 歴は当時 ～ 年） 現在はメール配信サービスの を担当
- 3. 発表の主なターゲット ● プロダクトの のバージョンアップについて正攻法を持っ ていない人 ●泥臭いバージョンアップが気になる人 ● 初級者が悪戦苦闘している頑張っている姿が 気になる人
- 4. 今日話すこと ● チャットディーラーとは ● ノウハウの無さが生んだ泥臭い作業 ●リリース ● トラブルのお話 ● バージョンアップの振り返り ● これからの との付き合い方 ● まとめ
- 5.
- 6.
- 7.
- 8. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ
- 9. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ Webサイトに埋め込まれて いるチャットを利用
- 10. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ CDを契約しているユーザが 管理画面を利用
- 11. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ
- 12. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ
- 13. バージョンアップ経緯 ● をバージョンアップすることになったきっかけ ○ 系を利用していたが年 月で を迎える ● 系ではなく 系にした理由 ○ 社内的に である必要があった ○ 系の は 年 月と次のリミットが近い ○ 系は まで 年 月までなので採用
- 14. バージョンアップ経緯 ● 社内での実績はあったのか？ ○ 過去別サービスでバージョンを上げた事はあるが ●ドキュメントなどの証跡は？ ○ 残っていない ● 経験者からヒントは得られないか？ ○ 恐らく動作確認をしただけだろうとのこと ○ に精通したエンジニアが少なくヒントは 得られなかった
- 15. 作業時系列 10月 11月 12月1月 2月 3月 計画作成 調査開始 調査完了 全機能テスト準備 全機能テスト1回目 負荷試験準備 改修作業 改修作業 全機能テスト2回目 負荷試験 全機能テスト3回目 リリース 年 年
- 16.
- 17.
- 18. ノウハウの無さが生んだ泥臭い作業 ● なぜ、泥臭かったのか？ ○ アナログな作業が多く、効率的では無かった ●なぜ、他の方法が無かったのか？ ○ ノウハウが無く、他の方法が分からなかった
- 19. ノウハウの無さが生んだ泥臭い作業 ● なぜ、泥臭かったのか？ ○ アナログな作業が多く、効率的では無かった ●なぜ、他の方法が無かったのか？ ○ ノウハウが無く、他の方法が分からなかった ● なぜ、調べなかったのか？ ○ 調査に使える時間が少なかった
- 20. ノウハウの無さが生んだ泥臭い作業 具体的には何が泥臭かったのか？ ● バージョンの変更確認 ○ の変更差分確認 ○依存パッケージの変更差分確認 ● 全機能テストを複数回実施 ○ チャット機能の全操作を網羅するテスト ○ 合計 回の全機能テストを実施
- 21. ノウハウの無さが生んだ泥臭い作業 具体的には何が泥臭かったのか？ ● バージョンの変更確認 ○ の変更差分確認 ○依存パッケージの変更差分確認 ● 全機能テストを複数回実施 ○ チャット機能の全操作を網羅するテスト ○ 合計 回の全機能テストを実施
- 22. ノウハウの無さが生んだ泥臭い作業 依存パッケージの変更差分確認 ● 利用している依存パッケージは 個 ○単純に数が多い ● 全てのバージョン差分確認 ○ 全てをドキュメントで確認するにも限界がある ● 系で利用可否確認 ○ 明記されてないものもあった
- 23. ノウハウの無さが生んだ泥臭い作業 ● 単純に数が多い ● 全てをドキュメントで確認するにも限界がある ○大きな変更のみ確認（深追いをしない） ○ に影響のありそうなものだけに絞る ● 系で利用可否が明記されてないものもあった ○ 公式のユニットテストを信頼
- 24. ノウハウの無さが生んだ泥臭い作業 ● 深い追いしなかった小さな変更の確認方法は？ ○ 全機能テストで挙動を確認 ●ユニットテストが実施されていない場合の確認方法は？ ○ 全機能テストで挙動を確認
- 25.
- 26.
- 27. ノウハウの無さが生んだ泥臭い作業 ● 全機能テストって大変なの？ ○ 全て手動 ○約 ケース ○ 慣れている人が実施しても１日では終わらない ○ 場合によってはマルチブラウザで実施
- 28. ノウハウの無さが生んだ泥臭い作業 ● 全機能テスト計画 ○ １回目：検証環境で系の動作確認 ■ 不具合洗い出しテスト ○ ２回目：改修作業後に再度確認 ■ 改修後の動作確認テスト ○ ３回目：結合環境でリリース前確認 ■ ステージング環境で動作検証テスト
- 29. ノウハウの無さが生んだ泥臭い作業 ● なぜ複数回実施する計画にした？ ○ 全機能で担保する重要性が増えたから ○自信を持って と言えなかったから ■ 経験不足 不安 ■ 社内で聞ける人がいない 不安 不安の現れから複数回実行することに
- 30. ノウハウの無さが生んだ泥臭い作業 ● 全機能テスト１回目 ○ 検証環境で系の動作確認 ■ 初作業ということもあり 時間かかる ■ テストは問題なく完了 ■ 改修箇所の洗い出し完了 ■ 少なくとも後２回全機能テスト
- 31. ノウハウの無さが生んだ泥臭い作業 ● 全機能テスト２回目 ● 全機能テスト３回目 ○一部、複数ブラウザも対応 ○ 回目、 回目共に約 時間ほどで実施 ○ テストは問題なく完了 ○ 成功しそうという自信（根拠はない）
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. トラブル発生 ● リリース後、数日が経ち に異変が発生 ○エンドユーザ利用側で動作遅延が発生
- 42. トラブル発生 ● サーバ監視ツールで確認 ○ 台あるチャットサーバ（）の 台で負荷が発生 ➔ 使用率が ％に
- 43. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ 遅延
- 44. 調査開始 ● を使用しているサーバが怪しい ○ 負荷が高まっているのはチャットサーバのみ ○数日前にバージョンアップを実施したばかり ○ 前述した泥臭い部分等の不安がある 別のサーバも調査するが、メインはチャットサーバ
- 45.
- 46.
- 47. 調査難航 ● 普段見ない箇所を調査 ○ サーバ監視ツールで普段見る事無いグラフを確認 ■使用率が上がるには何かしら兆候があるはず
- 48.
- 49.
- 50. 新たな疑問 ● はシングルスレッドでは？ ○ シングルスレッドならは動かないはず ○ は内部でマルチスレッドとして動いていると聞いた 事がある
- 51. がマルチスレッドなのか調べよう ● Node.jsではlibuvというライブラリを利用 ○ libuvはイベントループ機能を提供 ●下記プログラムにてデフォルトで複数スレッドを利用 ○ node/deps/uv/src/threadpool.c
- 52. がマルチスレッドなのか調べよう ● libuvの中でマルチスレッドを利用している ○ Node.jsを使用する際は隠蔽されているので 挙動はシングルスレッド ○内部でマルチスレッドを利用している場合もある ■ ファイルI/O・Crypto ■ 他にはどんな時にマルチスレッドになるのか？ ● ご存知の方がいれば教えて頂きたい
- 53. 現時点までで分かった事 ● 使用率の負荷とContext switchには関連がある ●Context switchの値が増加 ○ 待ち状態が発生し別スレッドを処理 ■ マルチスレッド処理になるような箇所が怪しい
- 54. トラブルの原因発覚 ● DBサーバを調査していたメンバーからの連絡 ○ スロークエリが発生している ○スロークエリの原因は管理画面サーバ チャットサーバ（Node.js）が原因では無かった
- 55. サーバ構成紹介 チャット画面サーバ（ ） サーバ 管理画面サーバ（ ） チャットサーバ（） エンドユーザ 管理ユーザ 遅延
- 56. トラブルの原因 1. 管理画面サーバから投げたSQLが原因でDBサーバが遅延 2. 共通のDBサーバを利用しているのでチャットサーバからの問 い合わせも待ち状態に 3.待ち状態のプロセスが増え遅延が発生 ● チャットサーバは通信数も多いので遅延が顕著に発生
- 57.
- 58. 何故 使用率が ％に？ ●使用率 ％の原因予測 同一処理の中でファイルへの書き込みと を利用する箇所があった 内部でマルチスレッド化し を 利用するが、 処理部分で待ち状態となる スレッドを切り替えるが全て待ち状態となり 使用率が上昇
- 59. 何故 使用率が ％に？ ●使用率って何？ ○ 使用率は 状態以外の状態とされている ○ 待ち状態でも 使用率は上昇する 今回 使用率が ％になった理由は恐らくこれ
- 60. トラブル解決に至るまでの問題点 ● チャットサーバ側に問題があると決めてしまった ○ 不安があったのですぐに疑った ●複数の要因により調査が難航した ○ Node.jsに対する知識不足 ○ Context switchやLinux低レイヤーなどの知識不足
- 61. トラブルが終結 ● Node.jsのバージョンアップによるものではなく一安心 ● 知識・経験不足を痛感 ○libuvなどのプログラムを読む良い機会になった ○ 今後も利用していくうえで、学習が必要
- 62.
- 63. バージョンアップを振り返り ● 予定通りリリースできた ● 結果的にバージョンアップ起因でのトラブルは無い ●社内での成功事例が出来た ● 泥臭い作業がしんどかった ○ 次回はもっと楽にしたい
- 64. バージョンアップを振り返り 具体的には何が泥臭かったのか？（おさらい） ● バージョンの変更確認 ○ の変更差分確認 ○依存パッケージの変更差分確認 ● 全機能テストを複数回実施 ○ チャット機能の全操作を網羅するテスト ○ 合計 回の全機能テストを実施
- 65. バージョンアップを振り返り ● もっと楽に出来そうなところ ○ 依存パッケージの変更差分確認 ■にとって重要な機能を洗い出しておく ■ 短いスパンでバージョンを上げる ○ 全機能テスト ■ 全機能テストの自動化
- 66.
- 67. これからの との付き合い方 ● もっとNode.jsの知識が必要 ○内部のプログラムを積極的に読む等 ● Node.jsに精通したエンジニアを増やす ○ 相談相手が欲しい… ● 次のバージョンアップを見据えた活動が必要 ○ より良いバージョンアップ方法を探す
- 68. これからの との付き合い方 ● より良いバージョンアップ方法を探す ○現時点で検討できること ■ 自動テスト（ユニットテスト・EtoEテスト）作成 ■ 余裕を持ったバージョンアップ作業の計画 ■ 情報交換を積極的に実施する ● 今回の発表もその一環
- 69.
- 70. まとめ ● 昔ながらの方法で をバージョンアップした ●苦労はあったが無事リリースすることができた ● トラブル調査で に対する理解が深まった ○ トラブルで得られる知識は一生もの ● 同じ悩みを抱えている or 解決した人がいれば 情報交換したいです ○ それ以外も大歓迎です
- 71.
- 72. 発表後の感想など… ● JSConf JPどうだった？ ○知らない技術の発表が沢山あり興味深かった。 ○ フロントエンドの最前線を肌で感じることができた。 ○ 英会話できるようになりたいな… ● 情報交換を積極的に実施できた？ ○ たくさん情報交換しました!! ○ いろんなエンジニアの方と知り合いました!!
- 73.