コード化されていない稼働中のサーバを移設_再構築する技術

Transcript

1. コード化されていない稼働中のサーバを移設/再構築する技術 渡部⿓⼀ SRE Kaigi 2025
2. • ⾃⼰紹介 • IaCの重要性 • コード化されていない稼働中のサーバを移設する具体的な⼿法 • まとめ アジェンダ
3. ⾃⼰紹介
4. • 名前: 渡部⿓⼀ • 所属: 株式会社IVRy SRE • SRE NEXT Co-Chair • 仙台在住 • 障害対応、EOL対応 ⾃⼰紹介
5. SRE NEXT • SRE NEXT 2025 ◦ 7⽉11-12⽇ TOC有明 ◦ テーマ「Talk NEXT」 ▪ カンファレンス内における会話（Talk）を通して各々次のアクション （NEXT）のためのヒントをより多く得られるような場の提供 ▪ サブイベントのRoad to SRE NEXTは再来週からやります！@京都 • コミュニティスポンサーとして枠をいただきました🙏
6. 株式会社 IVRy • 対話型⾳声AI SaaS ◦ 最⾼の技術をすべての企業に届ける • Architectureプロジェクト SREチーム ◦ 全⼈類が電話をかけてきても耐えられるサービスを⽬指す ◦ IaCしたりcoredumpみたりAIの指⽰で⼿を動かしています
7. IaCの重要性
8. インフラのコード管理してますか？
9. コード管理しないとどうなる？
10. • EC2を⽴ててそこにアプリを置いてサービスを起動 • とりあえずは動くし問題はなさそう • サーバがなんらかの原因で壊れると再構築が必要 • シンプルな構成ならすぐに直せそうだが複雑な構成だと復旧させるまで に時間がかかる ◦ どうやって構築したんだっけ？ ◦ 構築してもデプロイする⽅法が不明だ... ◦ 再度サービスを提供可能にするまでめちゃめちゃ時間がかかる 全てが⼿動で構築されたインフラ
11. • インフラの設定や管理をコードで表現し、⾃動化するアプローチ • 信頼性の⾼いインフラ運⽤が可能になる IaC（Infrastructure as Code）
12. • ⼀貫性と再現性の向上 ◦ ⼿作業で設定すると、ミスや設定のばらつきが発⽣しやすい • 変更管理と可視性の向上 ◦ ⼿動変更では誰がいつ何を変更したか分かりにくい • ⾃動化による効率化とコスト削減 ◦ ⼿動でのインフラ構築や設定は時間がかかり、⼈的リソースを消費 • リスク軽減と迅速な復旧 ◦ ⼿動での設定ミスや障害発⽣時の対応が遅れる IaC（Infrastructure as Code）
13. インフラをコードとして管理しよう
14. 代表的なIaCツール
15. • No • 静的なデータを配信するだけのWebサービスで⼀⼈で開発するのであれ ば不要だと考えます ◦ S3 + CloudFrontのような構成 (コラム) 信頼性の⾼いサービスにコード化は必須か？
16. イントロダクション
17. 過去にあった事例(フィクション)
18. • インフラエンジニアとしてとある部署に配属 • サービスは動いているしトラフィックもすごい量捌いている • サーバ台数も300台近い • 脆弱性の観点からOSの移⾏が必須となった • 移⾏するに当たって構成把握をしようとコードを探した • が、コード探すとどこにもなかった • 昔いた別部署の⼈に聞いてみると？コード？ないよと⾔われた • アプリケーションもGit管理されていなくてサーバにあるだけ 配属初⽇
19. どうする🤔？
20. • インフラの設計書があればその通りにコードを書いていけば良い • 昔に作られたインフラは設計書が残っているケースは少ない ◦ 私はこれまでに⾒たことがない... • ⼿動で構築されたサーバをどうにかしてOS移⾏する必要が出てくる 既存環境のコード化
21. 動いているものを正として構成を把握する
22. • リバースエンジニアリングに近いことが必要となる • 動いているサーバから情報を集めて移⾏先のOSで動かす 動いているものを正として構成を把握する
23. ⼿法の紹介
24. ⼿始めに実施する系
25. • とりあえずsshができたら⾒ていく • この時点である程度の規模感や⽅針が建てられる ⼿始めに実施する系
26. • ホスト名 ◦ 00xみたいな番号がついていれば冗⻑化されていそう ◦ 前段で振り分けている機構があると予想 • NIC ◦ IPアドレスからサブネットがわかる ◦ 複数NICある場合はそこからネットワーク構成が⾒れるケースも • OS ◦ /etc/os-releaseとかに書いてある 何はともあれsshして⾒れる情報を⾒ていく
27. • 動いているプロセスをみる ◦ プロセス名から⼤体の予想がつく ◦ 空いてるポート番号なども調べておく • CPU、メモリ、ストレージをみる ◦ ⼤量にCPUが積まれている場合はCPUバウンドな処理がある ◦ メモリがあればDBが動いている可能性 ◦ ストレージの使⽤量をみるのも⽤途の予想が⽴てれる 何はともあれsshして⾒れる情報を⾒ていく
28. • ⼊っているパッケージの調査 ◦ ディストリビューションはこの時点でわかっているので確認 ◦ RPMやAPTでいつ⼊ったのかやどこのリポジトリから取ってきてい るのか、どういったファイルを使っているのかを確認 ▪ 独⾃のリポジトリを使っているケースもあるのでわかった時点 でパッケージを保全しておくと安⼼ 何はともあれsshして⾒れる情報を⾒ていく
29. • ここまでで以下の情報がわかる ◦ スペック ◦ ホスト名、OS名 ◦ ネットワーク情報 ◦ 動いているプロセス ◦ ディレクトリ構成 ◦ パッケージ情報 まとめる(ここまでを10分くらいでやる)
30. • 使うコマンド例 ◦ CPU: lscpu ◦ Memory: free -h ◦ Disk: df -h、lsblk ◦ PCI: lspci ◦ Network: ip addr show、ip route show、netstat -tuln ◦ Package: RPM、APT、apk まとめる(ここまでを10分くらいでやる)
31. 具体的な調査
32. • アプリケーションを読んでいく ◦ LL⾔語の場合 ◦ コンパイル⾔語の場合 • ミドルウェアの設定ファイルをみる • 動いているプロセスの特徴を調べていく • 詳しそうな⼈を探す 具体的な調査
33. • アプリケーションが移⾏対象にはなるのでコードを読んでいく • どういったサービスでどういったミドルウェア上で動いているのかをコード から読み取っていく • アプリケーション固有の設定ファイルにはミドルウェアの設定情報などが書 かれているのでそういったものから情報をまとめていく ◦ database.yaml, application.rb アプリケーションを読んでいく
34. • LL⾔語の場合 ◦ OSのどこかにコードが落ちていればそのコードを読んでいく ▪ 死ぬほどデッドコードがあったりするので挙動の調査も別途⾏う アプリケーションを読んでいく
35. • コンパイル⾔語の場合 ◦ ソースがない場合はOSの移設は厳しい ◦ 同じOSでライブラリ類を⼊れれば動くかもしれないのでそれに期待 ◦ ビルドオプションをバイナリに含んでいるケースがあるので-hとかして 調べてみる ◦ ソースがある場合でも新しいOSでビルドできるとは限らない ◦ glibc のバージョンアップに伴い getaddrinfo(3) の動作仕様が変わった ▪ ソースの⽅を書き換えていく必要がある アプリケーションを読んでいく
36. 動いているプロセスの特徴を調べていく • procfs • tcpdump • strace • ftrace • ltrace • Scapy
37. • procfs は擬似ファイルシステム • 通常 /proc にマウントされ、実⾏中のシステムに関する情報を含んでいる ◦ CPU、物理メモリ、仮想メモリ、カーネルコマンドライン • 加えてプロセスごとの情報も確認することができる ◦ /proc/[PID] ディレクトリで取得できる ◦ プロセス名、状態、スレッド数、コマンドライン、pwd、環境変数、fd • psコマンドや、topコマンドのこのファイルシステムを使って情報を表⽰し ている procfs
38. procfs
39. • procfsではライブラリのリンク情報もわかる • /proc/[PID]/mapsでは以下の情報がわかる ◦ メモリアドレス範囲、アクセス権、ファイルパス ◦ どのようなミドルウェアに依存しているのかがある程度把握することが できる ▪ Goとかシングルバイナリだと情報はほぼない procfs
40. • オープンしているfdがわかるのでログファイルの場所やその他に書き込んで いるファイルを特定できる • 使っているポート番号も特定できる • FHSに準拠していれば/etc/にあることがわかるが準拠してないケースもある ◦ /etc/にそれっぽいものが置いてあっても本当に読んでいるかは不明 • ⼀⽅で設定ファイルはプロセスの初期化時点でclose(2)しているケースがほ とんどなので後述するstraceなどのツールを使ってパスを特定していく procfs
41. • sysfsも 擬似ファイルシステム • 通常 /sys にマウントされ、デバイスやドライバについての情報を含んでいる ◦ ブロックデバイス情報とかは取れるがVM環境の移設であればほぼ登場機 会はない 参考: sysfs
42. 参考: sysfs
43. • ネットワークパケットをキャプチャし分析するためのコマンドラインツール • プロセスが使っているポートに対して実⾏する • -Xでパケットの内容を16進数（hex）とASCIIの両⽅で表⽰することができる ◦ 昔のミドルウェアとかだと暗号化されていないのでここで割と⾒れる情 報が多かったりする ◦ バイナリプロトコルでもwiresharkとかに⼊れるといい感じにパースし てくれることも多い tcpdump
44. • システムコールレベルでプログラムの挙動を把握するためのツール • システムコールを通じて、プログラムがカーネルとどのようにやり取りして いるかを確認できる • ファイル操作やネットワーク通信、プロセス管理などのシステムコールを追 跡して問題を特定 • strace の -k オプションでスタックトレースを出す strace
45. strace
46. strace(-kオプションあり)
47. • プログラムが実⾏時に呼び出すライブラリ関数（ユーザースペースの関数） をトレースするツール • 主にCライブラリ（libc）やその他の共有ライブラリに定義された関数呼び出 しを監視できる • ライブラリ関数の引数や戻り値を追跡し、プログラムの内部動作を理解 ltrace
48. ltrace
49. • カーネル関数の呼び出しをトレースするツール • カーネルモジュールやドライバのデバッグ。 • カーネル関数の呼び出し順序や実⾏時間を調査。 • パフォーマンスのボトルネック解析 ftrace
50. strace, ltrace, ftrace
51. • Linuxカーネル内で動作するプログラムを安全かつ効率的に実⾏できる仕組み ◦ 元々はネットワークパケットのフィルタリングを⽬的とした技術 • システムトレースやパフォーマンス解析、セキュリティなど、幅広い⽤途で 活⽤されている • uprobeを使ってリバースエンジニアリングは可能そう • とはいえこれが使える環境は⽐較的最近のものなので⼿動で構築されてコー ド管理されてないVMに載ってるケースにはまだ出会っていない 参考: eBPF(extended Berkeley Packet Filter)
52. • パケット操作やカスタムプロトコルの解析に使⽤されるPythonベースの ツール ◦ パケット⽣成、送信、解析が可能 Scapy
53. • プロセス名やサービス名がわかればその辺のキーワードでGitHubやSlackな りを検索してみる • 退職していたらどうしようもないが部署異動であればその⼈を探して持って いる情報を聞き出すのもとても良いです 詳しそうな⼈を探す
54. • ここまでで以下の情報がわかる ◦ 設定ファイルの中⾝ ◦ アプリケーションの実装 ◦ どのようなコマンドで実⾏しているか ◦ なんのライブラリに依存している ◦ アプリケーションがどのプロセスと通信しているか ◦ 使っているプロトコルやそのバージョン まとめる
55. • 要件がある程度わかる • 移⾏先で何を動かせばいいのかがわかる • コードに落とし込んでいける • 移⾏できる！ まとめる
56. その他
57. • 紹介した例だとVMがあって要件がわからないケースでの事例 • 要件も⽤途もわかっているがコード化するのが⼿間というケースも結構 よく聞く • クラウド側にAPIがあればそれを元に⾃動でコード⽣成する ◦ GoogleCloudPlatform/terraformer 過去にGUIで構築されたリソースをコード管理
58. まとめ
59. • コード管理されていないインフラの移設は割と再現性のある技術の⼀つ • 信頼性の⾼いサービスを構築/運⽤するために必須の技術 • ⼀度コード化されたインフラは、新しい課題や変更にも柔軟に対応できる • IaCの恩恵を受け、障害復旧の迅速化、運⽤効率の向上、そしてサービス全 体の信頼性向上につなげましょう まとめ
60. 参考
61. • Linuxシステムプログラミング / オライリージャパン • Linuxプログラミングインタフェース / オライリージャパン • Infrastructure as Code / オライリージャパン • ふつうのLinuxプログラミング / SBクリエイティブ • ［試して理解］Linuxのしくみ / 技術評論社 参考書籍
62. 良いIaCライフを！！