現実世界のシステムにモダンなアーキテクチャを取り入れる技術

Transcript

1. 現実世界のシステムにモダンな アーキテクチャを取り入れる技術 株式会社ラクーンホールディングス 技術戦略部 井瀬篤
2. - 井瀬 篤 - ラクーンHD 技術戦略部 システム管理チーム 所属 (5年目) - SREっぽいこと - プラットフォームエンジニアリングっぽいこと - データエンジニアリングっぽいこと - 前職もインフラエンジニア (ネットワーク・セキュリティ系) - 趣味 自己紹介
3. マイクロサービス、Kubernetes、サーバレス、クラウドネイティブ… 本当にモダンなアーキテクチャでWebシステムを作っていますか？ 昔ながらの、サーバの上にアプリをぽんと置くだけ、という環境もまだ まだたくさんあるはず。 そんな環境の人は、モダンな技術とどんなふうに向き合っていけばいい でしょうか？ → 弊社システムのDockerコンテナ移行の事例を通して考えます！ 今日話すこと
4. 1. 既存システムの概要 2. どう変えていくか？ 3. 移行作業の流れ 4. やってみてどうだっか？ 目次
5. 1.既存システムの概要
6. - スーパーデリバリー - モール型のECサイト - 楽O市場みたいな感じ - 卸売 (事業者専用で一般消費者は購入できない) - サービス開始: 2002年 サービスについて
7. - 機能ごとにいくつかのJavaアプリが稼働 - なかには20年モノのアプリも - アプリは共通のDBを利用 - サーバは自社管理の物理サーバ上に構築された仮想サーバ システムの概要 ロードバランサー DB Webサーバ (画像・CSS・JS) APサーバ (ECサイト) APサーバ (管理画面)
8. 基本的な設計はサービス開始初期のまま、仮想化やアプリのリプレース などちょっとずつアップデートされ受け継がれてきた - デプロイ方法は？ - SCPでアップロードして… - アプリによってはデプロイスクリプトがある - エラーログは？ - SSHでtailして… - 設定変更は？ - SSHでコンフィグファイルを編集して… マイクロサービス？？？ クラウド？？？オートスケール？？？ ザ・レガシーシステム
9. 1. ビルド 1. ビルドサーバにsshでログイン 2. masterブランチをpull 3. ビルドコマンドを実行 2. 配布 1. APサーバにsshでログイン 2. 現用のjarファイルをバックアップ 3. ビルドサーバから新しいjarをscpでコピー 3. 適用 1. ロードバランサーからAPサーバを切り離すスクリプトを実行 2. APサーバでサービスを再起動 3. ロードバランサーにAPサーバを戻すスクリプトを実行 4. 動作確認 1. APサーバにsshでログイン 2. エラーログファイルをtail -fで半日ほど監視 リリース手順の例
10. 1. ビルド 1. ビルドサーバにsshでログイン 2. masterブランチをpull 3. ビルドコマンドを実行 2. 配布 1. APサーバにsshでログイン 2. 現用のjarファイルをバックアップ 3. ビルドサーバから新しいjarをscpでコピー 3. 適用 1. ロードバランサーからAPサーバを切り離すスクリプトを実行 2. APサーバでサービスを再起動 3. ロードバランサーにAPサーバを戻すスクリプトを実行 4. 動作確認 1. APサーバにsshでログイン 2. エラーログファイルをtail -fで半日ほど監視 リリース手順の例 アプリによって scpするものや 保存場所が違う ログの場所は？ どのサーバにssh すればいい？
11. 2. どう変えていくか？
12. - すでにオンプレのインフラがある・サービスがそこそこの規模 - クラウドのほうがコストが高くなるケースも - 事業者向けのサービスなのでトランザクションが安定している・ト ランザクション当たりの売上が大きい - チューニングやスケールアップで結構なんとかなる - 長年安定稼働し続けていて、改修の必要性が低い - サーバ一台で完結するシンプルさ ビジネスのニーズを考えよう！ モダンなシステム、みんなが必要？
13. - リリース作業でファイルをアップロードし忘れる - めったに更新がないアプリのリリース方法は長老の記憶の中 - 障害が起きたら、あっちこっちのサーバにSSHしてログをあさる - 手作業の設定変更をサーバの台数分繰り返す - サーバをリプレースしたら、必要なディレクトリが足りなくてアプ リが落ちる → 自動化しよう！ 辛いこと = システム変更の手間
14. サーバ構成管理をAnsibleで自動化した結果… → 構成のパターンが多すぎて管理しきれなくなった そもそも… - 自動化の強みは「同じ作業の繰り返し」 - サーバの構成がバラバラなままの自動化のメリットを活かせない 問題の根幹は… 構成がバラバラ = アプリと周辺システムが深く結合している 自動化すれば解決？
15. 外部システムとアプリの依存性 設定変更 デプロイ サーバ 設定 ファイルA アプリA ディレクトリ hoge 環境変数X サーバ 設定 ファイルB アプリB 環境変数Y アプリによって必要なものが違う -> アプリの数だけ周辺システムの構成パターンが生まれる ディレクトリ foo ディレクトリ bar NFSサーバ SCP
16. 技術の進化の傾向: レイヤーの深化 → 抽象度を高め、責務を分割し、他レイヤーとの疎結合化 アプリの仕様まで踏み込んだのが、クラウドネイティブ モダンな設計と疎結合化への志向 物理マシン ゲストOS コンテナ ミドルウェア・ライブラリ アプリ ハイパーバイザー 物理マシン アプリ OSすらなく、アプリが物理マシンのすべてを支配していた時代もあった…
17. クラウドネイティブ = クラウドを前提にしたアプリ → 環境依存が少ない → オンプレでも扱いやすい クラウドネイティブの技術と設計原則を取り入れたシステムへ！ - Dockerコンテナ - Twelve-Factor App クラウドネイティブで、どこでも動く化
18. ビルド・デプロイシステム Dockerコンテナ化 サーバ コンテナイメージ 設定 ファイル アプリ ディレクトリ 環境変数 設定変更 デプロイ サーバ 設定 ファイル アプリ ディレクトリ 環境変数 ポート サーバ 設定 ファイル アプリ ディレクトリ 環境変数 Dockerfile docker build コンテナ サーバ コンテナ docker pull docker run
19. アプリをDockerコンテナ化して、環境依存を閉じ込めDockerfileで管理 → 依存性を囲い込むことでアプリの周囲のシステムをシンプルに・共通化 - ビルド: コンテナイメージを作るだけ (docker build) - デプロイ: 起動するコンテナイメージを入れ替えるだけ (docker pull) - サーバ: コンテナイメージを起動するだけ (docker run) Dockerコンテナ化
20. 目標: アプリの外部環境依存を減らして、周辺システムを共通化する やること: - Dockerコンテナ化 - Twelve-Factor Appに近づける - 共通周辺システムの構築 (サーバ・ビルド・デプロイ・開発環境など) やらないこと: - アプリの大幅な改修 (マイクロサービス化など) - インフラの大幅な改修 (Kubernetesなど) やること
21. APサーバ(ECサイト) APサーバ(ECサイト) APサーバ(ECサイト) APサーバ(ECサイト) APサーバ(ECサイト) APサーバ(ECサイト) システム構成 APサーバ(ECサイト) コンテナ ロードバランサー APサーバ(管理画面) コンテナ Webサーバ コンテナ DB GitLab Dockerfile コンテナ イメージ Jenkins Elasticsearch Fluentd ログ
22. アプリの実行 APサーバ systemd Java アプリ docker compose up docker- compose.yml version: ‘3’ services: app: image: gitlab/superdelivery/ec-app:$COMMIT_HASH docker-compose.yml Jenkins COMMIT_HASH 環境変数を書き換え - サーバ上にdocker-compose.yml があり、systemdがdocker compose upすることでアプリが 起動する - コンテナイメージはタグの部分 が環境変数になっており、 Jenkinsで環境変数定義ファイル を書き換えることで、イメージ を切り替えることができる
23. Jenkinsでデプロイ
24. 3. 移行作業の流れ
25. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 進め方
26. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 1. 準備・設計
27. 例1) リポジトリ間でデプロイのタイミングに依存性がある アプリが返したHTML内で参照されるCSSが別リポジトリにある場合 1. 準備・設計 - システムの依存関係を把握する APサーバ Webサーバ ECサイト アプリ (Java) Apache 画像・CSS など ブラウザ HTML リポジトリA リポジトリB
28. 例1) リポジトリ間でデプロイのタイミングに依存性がある - 1つのデプロイジョブで複数のリポジトリ対応が必要 - デプロイジョブはアプリのリポジトリとは別に管理 - アプリのリポジトリにはコンテナイメージに必要なものだけ入れる 1. 準備・設計 - システムの依存関係を把握する ECサイトアプリ用 リポジトリ ソース コード Dockerfil e GitLab-CI 静的ファイル用 リポジトリ CSS 画像 Dockerfil e GitLab-CI デプロイジョブ用 リポジトリ スクリプト Jenkinsfile
29. 例2) ファイルの受け渡し方法がバラバラ NFSに統一する改修を実施 1. 準備・設計 - システムの依存関係を把握する APサーバ バッチサーバ ECサイト アプリ (Java) バッチ① ファイル NFSサーバ バッチ② ファイル SCPで読み込み NFSで読み込み 出力 出力
30. 例3) ローカルコマンド実行 - アプリからsendmailコマンドを実行してメール送信していた - コンテナ内にPostfixを立ち上げることができないので、ネットワ ーク経由(SMTP)で連携するように変更が必要 1. 準備・設計 - システムの依存関係を把握する APサーバ ECサイト アプリ (Java) Postfix sendmail コマンド メール送信 インターネット APサーバ Postfix メール送信 インターネット ECサイト アプリ (Java) SMTP
31. 1. 準備・設計 - 設計ガイドラインを作成する ガイドラインをまとめる → Twelve-Factor Appを ベースに具体的なルールを 作成
32. ガイドラインの内容 - 環境固有の設定は環境変数で定義 - ファイルの保管・受け渡しはNFSサーバに限定 - docker volume・バインドマウントは原則利用不可 - 1トランザクションの処理時間の上限は5分 - グレースフルシャットダウンの待機時間 - ログは標準出力にJSON形式で出力 - ログフォーマットの必須フィールド - @timestamp: 日時をISO8601(TZあり・ミリ秒精度)形式で - level: 次のいずれか → DEBUG|INFO|WARN|ERROR|FATAL - type: ログフォーマット識別用 ※次ページで解説 - message: ログの本文 1. 準備・設計 - 設計ガイドラインを作成する
33. ログフォーマットについて - フォーマットがバラバラだと集約や検索するときに問題になる - どんなログでも存在するであろうフィールドをガイドライン化 - その他のフィールドの追加は任意 - 1) どのログにどんなフィールドが存在するか、2) 複数のログで同名 のフィールドがあるが意味合いが異なる場合に区別するため、typeを 利用する - typeにはLoggerの名前を使用するケースが多い 1. 準備・設計 - 設計ガイドラインを作成する {“type”: “file_dl_func”, path: “/download/shita/file”, “size”: 142} → 142KB のファイルを/download/shita/fileにダウンロードした {“type”: “access_log”, path: “/shouhin/osara1”, “size”: 254430} → /shouhin/osara1 にアクセスがあって 254.43KB 返した
34. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 2. システム基盤の構築
35. テスト環境 2. システム基盤の構築 - 開発・テスト環境 テスト環境を作るためのJenkinsジョブ テスト環境操作用のジョブが作成される！
36. テスト環境 2. システム基盤の構築 - 開発・テスト環境 コミットハッシュを指定して実行するとコンテナが起動する
37. 開発環境 - VS Code - Docker in WSL デザイナーさんでも使い やすいようにGUIのイン ストーラを開発 2. システム基盤の構築 - 開発・テスト環境
38. CI/CDシステム - GitLab CI - Jenkins 2. システム基盤の構築 - 開発・テスト環境 ログ基盤 - Fluentd - Elasticsearch - Kibana
39. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 3. アプリの修正
40. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 4. 開発・テスト環境の移行
41. 1. 準備・設計 ◦ システムの依存関係を把握する ◦ 設計ガイドラインを作成する 2. システム基盤の構築 ◦ 開発・テスト環境 ◦ CI/CDシステム ◦ ログ基盤 3. アプリの修正 ◦ 設計ガイドラインに合わせる ◦ Dockerfileを書く ◦ CIを導入する 4. 開発・テスト環境の移行 5. 本番環境の移行 5. 本番環境の移行
42. 4. やってみてどうだっか？
43. 1. ビルド 1. ビルドサーバにsshでログイン 2. masterブランチをpull 3. ビルドコマンドを実行 2. 配布 1. APサーバにsshでログイン 2. 現用のjarファイルをバックアップ 3. ビルドサーバから新しいjarをscp でコピー 3. 適用 1. ロードバランサーからAPサーバを 切り離すスクリプトを実行 2. APサーバでサービスを再起動 3. ロードバランサーにAPサーバを戻 すスクリプトを実行 4. 動作確認 1. APサーバにsshでログイン 2. エラーログファイルをtail -fで半 日ほど監視 リリース手順の例 1. ブラウザでJenkinsを開く 2. リリースしたいリポジトリに対応したジ ョブを選択する 3. リリースしたいコミットを入力してジョ ブを実行する 4. エラーが起きればSlackに通知がくるの でチェックする
44. - エンジニア・デザイナーからは好評 - 特に開発・テスト環境やログ調査 - 環境の変化もあまり抵抗なく受け入れてもらえた - 誰かがやってくれるのを実はみんな待っていたのかもしれない - 開発環境のトラブルも減った - 開発環境がWSL内に閉じているので、トラブルがあれば、 まるごと作り直せばいい - 改善が必要な点も - 環境変数の管理が煩雑だった - CI/CDなどを管理するプラットフォームエンジニアが不足 - NFSに扱いづらさがあるので、オブジェクトストレージに移行 するべき やってどうだったか？
45. - オンプレや歴史の長いレガシーなシステムでもモダンな設計思想は 活かせる！ - クラウドネイティブ = どこでも動く化！ - クラウドネイティブの設計原則を取り入れることで、周辺システム への依存を減らして変更しやすいシステムへ！ まとめ