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