Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rancherを活用した開発・運用効率の改善への取り組み

524 views

Published on

Rancher & DockerでDevOps!〜エンタープライズのためのコンテナー基盤セミナー〜 発表資料。

Rancher / DevOps / Docker

Published in: Technology
  • Be the first to comment

Rancherを活用した開発・運用効率の改善への取り組み

  1. 1. ©Internet Initiative Japan Inc. ‐ 1 ‐‐ 1 ‐ Rancherを活用した開発・運用効率の改善への取り組み 株式会社インターネットイニシアティブ 寺田 充毅
  2. 2. ©Internet Initiative Japan Inc. ‐ 2 ‐‐ 2 ‐ 自己紹介 & チーム紹介  名前:寺田 充毅(みちたか)  IIJのクラウド本部の分散技術課というチームに所属しています  IIJ GIO(IIJのクラウド)のs3互換オブジェクトストレージを担当して  ソフトウェアのエンジニアで主にJavaを書いて仕事をしています  前職では産業系のSIや、金融パッケージの開発・導入支援をやっていました
  3. 3. ©Internet Initiative Japan Inc. ‐ 3 ‐‐ 3 ‐ 目次 Rancherを使って何を改善したいのか Rancherを開発フェーズに適用する Machine Driverを利用した伸縮自在な解析基盤を作る
  4. 4. ©Internet Initiative Japan Inc. ‐ 4 ‐‐ 4 ‐ Rancherを使って何を改善したいのか
  5. 5. ©Internet Initiative Japan Inc. ‐ 5 ‐‐ 5 ‐  内製のs3互換ストレージ  サービスを構成する各AppがREST APIでつながっている  サーバ台数は二ケタ前半 フロントサーバ(外部向けREST API) 担当サービス:IIJ GIO ストレージ&アナリシスサービス メタデータ管理 契約管理 分散ファイルシステム インターネット ※アナリシス、コンソールは省略。 分散DB
  6. 6. ©Internet Initiative Japan Inc. ‐ 6 ‐‐ 6 ‐ このサービスの運用課題 : リリース  リリースがストレス • ソフトウェア改善を阻害 • モチベーション下がる  なにが原因なのか? • デプロイ作業に手作業が混ざり、作業量は多く、精神的負荷が高い • 予想外のことがデプロイ作業で起きやすい構造的な問題 • デプロイと構築が一体化してChefレシピになっている  即効性を求め、ローリングアップデートを後付け • 成熟度不足で、本番障害を引き起こす  根本的な見直しを考える CI/CDパイプラインを開発段階から育て、成熟した状態で本番を迎えたい コードによるインフラ定義は踏襲しつつデプロイをとにかくシンプルにしたい
  7. 7. ©Internet Initiative Japan Inc. ‐ 7 ‐‐ 7 ‐  Chefは疲れた  デプロイ=コンテナを起動するだけというシンプルな仕組みへ  ただし・・・ • 各サーバに入ってデプロイしているようでは作業効率は改善しない • 現実的にはコンテナの関連や、依存する資源(NW, ストレージ)の制御も必要 コンテナベースのシステムに変える うちのChefの担当範囲 環境構築とデリバリを 分けて考えていない アプリの依存物をコン テナにパッケージング 現 在 コ ン テ ナ 化 http server OS lib/conf 依存エンド ポイント App - A OS lib/conf 依存 App - B OS lib/conf 依存 DB/Storage OS lib/conf 依存 docker OS http server lib/conf Base image docker OS App - A lib/conf Base image docker OS App - B lib/conf Base image docker OS DB/Storage lib/conf Base image エンド ポイント
  8. 8. ©Internet Initiative Japan Inc. ‐ 8 ‐‐ 8 ‐ 理想を考えてみる  ソフトウェア開発者としての暴論 • リリースしたアプリケーションが、どこかで健全に動作し、顧客にサービスを提供していれば それで良い  理想的にはこうなるのか? • 開発者はイメージでアプリケーションをリリース • サービスの構成と必要なリソースを定義すれば自動で構築、アップグレードされる • 監視、及びその維持、復旧もお任せ(障害、負荷、セキュリティ侵害) • サービスのエンドポイントの管理もお任せ • 基盤の実体は抽象化されている イメージ 環境定義 endpoint 理想を実現して くれるなにか 開発者 顧客はサービスを いつでも使える
  9. 9. ©Internet Initiative Japan Inc. ‐ 9 ‐‐ 9 ‐ コンテナ管理基盤、オーケストレータ 現実に戻って考えると、オーケストレータは理想に近い Kubernetes(k8s) meetupに参加 • 導入が大変だという話多数 • 敷居の高さを感じた k8sではスモールスタートできないと判断 • 説得力のあるデモを作り、周りを巻き込みたい • 1人でも挫けないようなシンプルなオーケストレータが良い たまたまRancherを知る • 本格的なエンタープライズ向けプラットフォーム お手軽に始められそうだし、やってみよう • meetup #1に参加して感触を得た
  10. 10. ©Internet Initiative Japan Inc. ‐ 10 ‐‐ 10 ‐ Rancherを開発フェーズに適用する
  11. 11. ©Internet Initiative Japan Inc. ‐ 11 ‐‐ 11 ‐ 適用対象の検討 – 本番はまだ無理  本番適用は見送り • ストレージサービスは可用性、データ完全性への要求が極めて高い • コンテナへの信頼が我々の中で低い • ノウハウもない  お試しプロジェクトをやってみることに  題材:開発中のNFSサーバのCI/CDパイプラインを作る • オブジェクトストレージをバックエンドにした容量無制限のNFSサーバ  CI/CDパイプラインのうち、実現範囲はこのあたり バージョン 管理 UT デプロイ 自動 テスト 本番 デプロイ デプロイ 後評価・ 検証 ビルド
  12. 12. ©Internet Initiative Japan Inc. ‐ 12 ‐‐ 12 ‐ CI/CDのゴールと、実現のための道具  ゴール  Rancherの担当領域はテスト – デプロイ – 運用の範囲なのでその他の要素は別途用意 Develop Build Package Test Deploy/Upgrade Operate Docker Hub ソースへのtag打ちをトリガに自動でビルド、イメージ作成、環境構築、試験、 環境破棄を行うパイプラインを作る
  13. 13. ©Internet Initiative Japan Inc. ‐ 13 ‐‐ 13 ‐ 今回の構成  オーケストレータはRancher lab.のCattleを利用  アカウント管理は社内Githubを利用  データはコンテナ外に出した(nfs, MySQL)  イメージはプライベートなDocker Registryを構築して利用 Registry自社オブジェクト ストレージ 社内Github Server MySQL jenkins Agent Agent Agent nfs- ganesh アカウント連携 ソース取得 GlusterFS ※オンプレミスで構築
  14. 14. ©Internet Initiative Japan Inc. ‐ 14 ‐‐ 14 ‐  gitのタグ付けを契機にテスト実行(定期実行もしている)  試験が成功した場合はボリューム、スタックを削除する仕組み CI/CDパイプラインの全体像 2. タグ付けを契 機に処理開始 10 .テスト実行(httpで投げ込む) 5. ボリューム作成 7. カタログ install 8. スタック を展開 6. ボリューム作成 (実体はディレクトリ) 9. 各ノードがイメージPULL 1. タグ付け 処理用ホスト 処理用ホスト スタック NFS ServerClient GlusterFS 3. イメージ ビルド 4. イメージをPUSH 開発者の作業はこれだけ
  15. 15. ©Internet Initiative Japan Inc. ‐ 15 ‐‐ 15 ‐ 補足:カタログ  Rancherの用語 • スタック : アプリケーションを実現するためのサービスの集合 • カタログ : スタックのテンプレート(設計図)  カタログを実環境に展開するとスタックができる  カタログは自分で簡単に作成できる • rancher-compose.ymlとdocker-compose.ymlを作ってgitに置くだけ • バイブル「Rancher プライベートカタログとCompose」という資料 スタックカタログ
  16. 16. ©Internet Initiative Japan Inc. ‐ 16 ‐‐ 16 ‐ エラーの追跡に課題が見つかる  テストの追加によりITが長時間化  I/Oエラーが起きるものの.....追跡がうまくできない  なぜ? • NFSサーバが大量にログを出力するため一定サイズのログだと流れる • トレースレベルにするとIT一周で数10ギガオーダーに達する • メトリクスを後から追えない • I/O負荷?CPU使用率高騰?メモリリーク?を切り分ける情報が蓄積されていない  ログ収集、メトリクス収集&監視に取り組む他ない  本番で必須となる機能なので前向きに取り組む
  17. 17. ©Internet Initiative Japan Inc. ‐ 17 ‐‐ 17 ‐ 監視 - Prometheusカタログの利用  Prometheus = オープンソースの監視、アラートシステム  コンテナ、ホスト、Rancherサーバのメトリクスをかき集めてくれる  時系列DBに蓄積されたメトリクスをクエリしてGrafanaで可視化する仕組み
  18. 18. ©Internet Initiative Japan Inc. ‐ 18 ‐‐ 18 ‐ Prometheus まとめ  効果 • 過去データに遡りエラー原因の切り分けに活用できた(想定通り) • カスタマイズが簡単 • コンテナの負荷状況が俯瞰できる • Rancherに無い画面 • 思いもよらぬコンテナが高負荷かけているのを発見  冗長化が課題 • 複数立ててActive/Activeというアプローチを検討中 • 過剰検知への対策が必要  コンテナの監視はサーバの監視と様子が違う • 数が多い • 可視化時にスタック毎にグループ化するなど工夫が必要 • 動的に増減する • 状態の変化に追従するような監視ツールが必須
  19. 19. ©Internet Initiative Japan Inc. ‐ 19 ‐‐ 19 ‐  fluentdでログ収集し、オブジェクトストレージへ転送する  Dockerのログドライバの仕組みを利用  fluentdはコンテナに詰め、全ホストに一つずつ配置した • Cattleのスケジューラを利用 • カタログ化した  fluentdコンテナはホストネットワークに直接接続 • Dockerからはlocalhostにtd-agentがいるように見えている ログ収集 – fluentdログドライバ App オーバーレイネットワーク ホスト側のネットワーク ス ケ ジ ュ ー リ ン グ (global service)指定し て全ホストに配置 App App 自社のオブジェクト ストレージ
  20. 20. ©Internet Initiative Japan Inc. ‐ 20 ‐‐ 20 ‐ まとめ:Rancherの良かった点、悪かった点  良かった • カタログによりアプリケーションの効率的な管理が実現できる • アプリケーションとその実行環境を一括して管理、デプロイできる • CI/CDパイプラインの作成が簡単にできる • 強力なCLIがあり、たいていの操作は自動化できる • 簡単かつ失敗の少ないデプロイ • Blue/Greenデプロイなど試して行きたい  悪かった • たまにエラーに遭遇 • バージョンアップで解決 • 頻繁なバージョンアップにどうやって追従するべきかが悩み  その他 • 度々壊れるDocker & 巻き添えにあうホスト • 悩まずホストを捨て、RancherOSで簡単に再構築 • 現状構成のNFSの遅さがつらい • 割り切ってローカルボリュームの利用も考え始めている • DBなどI/O重視のものは我々のレベルでは無理にコンテナに詰めないほうが無難か
  21. 21. ©Internet Initiative Japan Inc. ‐ 22 ‐‐ 22 ‐ Machine Driverを利用した伸縮自在な 解析基盤を作る
  22. 22. ©Internet Initiative Japan Inc. ‐ 23 ‐‐ 23 ‐ サービスのログ解析は思ったよりコストが高い  1日で数10ギガのログが集まるため、数か月分しか保存、解析できない  前年同月との傾向比較ができるよう改善したい  コスト圧縮のアイデア = 自社のクラウドを活用する • ログをオブジェクトストレージに置く • 解析用のホストは必要に応じて構築、破棄をする Agent Worker Server 自社のオブジェク トストレージ Coordinator ... ログ蓄積解析・可視化 今回はこれもストレージ& アナリシスサービス サービスシステム ログ生成 Agent Worker Agent Worker 弾力的に台数を増減させる
  23. 23. ©Internet Initiative Japan Inc. ‐ 24 ‐‐ 24 ‐ ホストの増減はMachine Driverを利用  Machine Driver = RancherがRancherホストを構築してくれる機能  GUIから1~11台一気に構築できる(CLIでも実行可能)  弊社「IIJ GIO P2」も対応しました
  24. 24. ©Internet Initiative Japan Inc. ‐ 25 ‐‐ 25 ‐  IIJ GIO P2 Machine Driver を使ってワンクリックでホスト追加 • 無駄にサーバを抱える必要がない • 長期間のログでも解析できる  複雑な解析クエリも投げられるようになった • 前: 1月弱・前処理済みデータ(複数リクエストの主要な統計値だけをアグリゲート) • 後: サービスリリース以降すべて(3年間)・生ログ  レスポンスを上げるべくチューニング中 VM 契約から起動まで全自動でできる
  25. 25. ©Internet Initiative Japan Inc. ‐ 26 ‐‐ 26 ‐  IIJ GIO P2のTerraformのドライバを開発中  HA構成のRancherサーバ、Gitlab(レジストリ/CI)、PrometheusをIIJ GIO P2に 一発展開できるようにしたい  弊社「DNSアウトソース」サービスとRancherを連携する仕組みも検討中 パブリックリソース IIJ GIO P2とRancher ※個人的な構想※ ・ ・ ・ agentagent GUIか らサー バ追加 ネットワーク オプション ストレージ オプション 仮想サーバ VMware プラットフォーム 物理サーバ プライベートリソース ネットワーク オプション ストレージ オプション NASストレージ(NFS・CIFS) ストレージリソース その他 IIJ サービス ストレージ& アナリシス サービス DNS アウトソース サービス Server CIサーバ 兼レジストリ 構築 API連携で DNSレコー ドを更新 モニタリング &アラート Server
  26. 26. ©Internet Initiative Japan Inc. ‐ 27 ‐‐ 27 ‐

×