• ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル
  • ブログ
  • 製品
    • PagerDutyの製品機能
      • アラートの集約と分類
      • サービスとチームの組織
      • システム&ユーザーレポート
      • プラットフォームの拡張性
      • モバイルでのインシデント管理
      • ライブコールルーティング
      • リアルタイムコラボレーション
      • 事後検証から学び改善する
      • 多様なアラート機能
      • 簡単なスケジューリング
      • 信頼性の高い環境
      • エンタープライズレベルのセキュリティ
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • 事例
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • 価格

  • お問い合わせ
  • Why DSC?
  • 無料トライアル

マイクロサービス時代のモニタリング

  • On 2017年12月19日
  • Blog

迅速性の高まりにつれて増大する複雑さの管理

 

DockerとDevOps革命のおかげで、マイクロサービスはアプリケーションを構築して展開する新しい方法として浮上しました。マイクロサービスのトレンドを受け入れる理由はたくさんあります。

 

マイクロサービスを採用する場合は、マイクロサービスアーキテクチャには多くの部品があることも理解しておく必要があります。 インシデント管理に関して言えば、マイクロサービスとモノリシックアーキテクチャの間に重要な違いがあります。 部品が多いほど、アプリケーションとインフラストラクチャの健全性と継続性を維持するために、監視と管理がより複雑になります。

 

マイクロサービスがいかにIT監視の課題を増やすか、そして増大する複雑さを組織がどのように処理すべきかを探ってみましょう。

 

マイクロサービスの定義

 

マイクロサービスは、他のマイクロサービスと組み合わせて完全なアプリケーションを形成する小さなアプリケーションコンポーネントです。 Dockerを使用してアプリケーションをデプロイする場合は、複数のコンテナで構成されている可能性があります。各コンテナは個別のマイクロサービスを実行します。

 

DevOpsはソフトウェアの継続的デリバリーを奨励しているため、マイクロサービスはこの数年間で普及してきました。管理者はアプリケーション内の特定のマイクロサービスの問題を追跡できるため、マイクロサービスとして配備されたアプリケーションは管理しやすくなります。アプリケーションの特定のコンポーネントへの更新では、アプリ全体ではなくそのマイクロサービスだけを再起動できるため更新するのも簡単です。以上のような理由から、マイクロサービスは継続的デリバリーを容易にします。

 

2013年にDockerが導入されたことで、マイクロサービスへの関心が高まりました。Dockerコンテナは、マイクロサービスのための便利なビルディングブロックを提供し、モノリシックアーキテクチャに従って設計されたレガシーアプリケーションをマイクロサービスモデルに移植しようとする際に容易な移行パスを提供します。

 

複雑さ:マイクロサービスのトレードオフ

 

マイクロサービスを採用している組織は、インフラに追加する複雑さを考慮する必要があります。モノリシックアプリケーションがマイクロサービスアプリケーションに変換されると、管理者が監視すべきパーツが増大します。

 

たとえば、フロントエンドとデータベースがそのアプリケーション専用の仮想サーバ上で単一のアプリケーションとして実行される、モノリシックなWebアプリケーションを考えてみましょう。このアプリケーションの監視は比較的簡単です。その一部がダウンすると、アプリ全体がダウンします。監視するホストは1つだけであり、対処するアラートも1つだけです。このようなアプリは、異なるポート間の接続やサーバとデータベースのプロセスを監視することで事足ります。

 

ここで、コンテナのセットとしてデプロイされた同じアプリを考えてみましょう。単一の仮想サーバでアプリケーションを単純なプロセスとして実行する代わりに、フロントエンドとデータベースのレイヤーを異なるプロセスとして実行しているアプリです。Dockerはたくさんのプロセスを起動します。スケールアウトするようなアプリでは、おそらく何百ものコンテナがそれぞれのプロセスを担当するでしょう。コンテナの数はアプリケーションの要求に応じて絶えず変化します。さらに、アプリケーションの統計を収集するなどのタスクを担当するコンテナも抱えることになります。アプリケーションの可用性とパフォーマンスを保証するには、Dockerデーモン自体はもちろんのこと、これらすべてのコンポーネントを監視する必要があるため複雑です。

 

念のために言えば、私はマイクロサービスが悪いアイデアであるとは全く考えていません。上記の例では、マイクロサービスバージョンのWebアプリケーションは、モノリシックバージョンよりもはるかに拡張性と機敏性が高くなります。スケールアウトの敏捷性には、監視作業を増やすだけの価値があります。

 

マイクロサービスを効果的に監視する方法

 

効果的なマイクロサービス監視戦略には、2つの事実に注意が必要です。

 

明らかなのは、マイクロサービスでは監視すべきコンポーネントが増えているということです。しかし利用するインシデント管理プラットフォームが多数のアラートを処理したり、トライアルを支援したり、適切な人にルーティングしたりする能力を十分に備えていれば、これはさほど大きな問題ではありません。さらに、マイクロサービスではアラートの量がはるかに多くなるため、インシデント管理プラットフォームではアラートノイズを減らす必要があります。関連するアラートをグループ化したり、必要な対応を関連付ける一方、対応不能なアラートは抑制する必要があります。

 

もう1つ、やっかいな事実は、マイクロサービスが複雑になると、管理者にとってインシデント管理の役に立つ情報の量も増えることです。これは良いことです。モニターするコンポーネントが増えれば、対処すべきデータが増えますが、その余分なデータを活用して問題を特定することができます。モノリシックアプリに関連するアラートは、単にそのアプリのどこかに何か問題があることだけを伝えるため、問題の内容を正確に把握することはあなたの努力次第です。しかし、マイクロサービスでは、個々のDockerコンテナからのアラートにより、管理者は事件の原因となったアプリ内の正確なマイクロサービスを特定することができます。そして、アプリケーションが依存する他のコンテナを中断することなく、そのコンテナのインシデントを解決できます。

 

マイクロサービスは、インシデント管理チームにチャレンジとチャンスの両方を提供します。インフラストラクチャはより複雑になりますが、インシデント対応をより効果的かつ容易に行うことができます。マイクロサービスのモニタリングの鍵は、モノリシックなアプリの監視とマイクロサービスで構成されたアプリの監視の違いを理解し、マイクロサービス対応のインシデント管理ソリューションとワークフローを適切に配置することです。

0 Comments

Recent Posts
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Product Tags
AWS Blog DevOps News Post Mortem SecOps signalfx Slack SRE インシデント インテグレーション オンコール・スケジュール オンコール管理 スケジューリング ステークホルダー ビジネス関係者 モニタリング モバイル リリース 事後検証 導入事例Video 更新 製品アップデート

インシデント管理による優れたSecOps

余計なアラートを抑制しよう!

Scroll
会社情報

株式会社Digital Stacks

〒141-0001

東京都品川区北品川5-5-15

大崎ブライトコア 4F SHIP 414


  • Home
  • 製品情報
    • PagerDutyの製品機能
    • 操作画面の特徴
    • 開発者の責任
    • 部門ごとのPagerDuty活用法
    • ITの運用
    • ビデオで学ぶPagerDuty
  • サポート
    • FAQ
    • インテグレーションガイド
    • 日本語サポートサイト
  • DSCが選ばれるポイント
  • 価格
  • お知らせ
    • お知らせ一覧
      • 更新情報
      • メディア掲載情報
      • 受賞情報
  • 更新情報
  • PagerDutyの製品機能
    • アラートの集約と分類
    • サービスとチームの組織
    • システム&ユーザーレポート
    • プラットフォームの拡張性
    • モバイルでのインシデント管理
    • ライブコールルーティング
    • リアルタイムコラボレーション
    • 事後検証から学び改善する
    • 信頼性の高い環境
    • 多様なアラート機能
    • 簡単なスケジューリング
    • エンタープライズレベルのセキュリティ
  • PagerDuty導入事例
    • 導入事例インタビュー:株式会社ミクシィ
    • 導入事例インタビュー:イーサポートリンク株式会社 
    • 導入事例インタビュー:株式会社いい生活
    • 導入事例インタビュー:株式会社Jストリーム
    • 導入事例インタビュー:SmartNews 尾形暢俊氏
    • 導入事例:IBM Cloud
    • 導入事例:IBM Smarter Workforce
    • 導入事例:GREE
    • 導入事例:Panasonic
    • 導入事例:Evernote
    • 導入事例:Backcountry
    • 導入事例:Groupon
    • 導入事例:SendGrid
    • 導入事例:Brightcove
    • 導入事例:Code.org
    • 導入事例:インディアナ大学
    • 導入事例:Signal Sciences
更新情報
  • Japan IT Week 春 出展報告 2022年4月19日
  • PagerDutyをJapan IT Week 春に出展します 2022年3月21日
  • インシデントフローと対応の省力化を実現するPagerDuty&Rundeckを出展~Japan IT Week 秋 2021年11月10日
  • システム運用を強力に支援するPagerDutyとRundeckをJapan IT Week秋に出展 2021年10月25日
  • DevOpsのROIを測定する方法 2021年8月23日
  • 8/25 CEDEC 2021でCI/CDツールHarnessとインシデント管理ツールPagerDutyの活用例を紹介 2021年8月20日
  • PagerDuty Summit 2021の概要 Part 2 2021年7月12日
  • PagerDuty Summit 2021の概要 Part1 2021年7月2日
  • 6月23日-25日 PagerDuty Summit 2021 バーチャル開催のご案内 2021年5月20日
  • DevOpsを高速化するための6つのステップ 2020年10月15日
Copyright © Digital Stacks Corporation. All Rights Reserved.
  • 無料トライアルを申し込む
  • お問い合わせ
  • 販売会社情報
  • 個人情報保護方針
  • サイト利用規約