Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mackerel MeetUp #10用発表資料

mdadm
April 27, 2017

Mackerel MeetUp #10用発表資料

前回LT内容のブラッシュアップ(;゚∀゚)=3

mdadm

April 27, 2017
Tweet

More Decks by mdadm

Other Decks in Business

Transcript

  1. .
    で支えるエムティーアイの
    ヘルスケアプラットフォーム
    MTI Ltd.
    N.akama
    @mdadm

    View full-size slide

  2. .
    2
    弊社サービスのご紹介
    【音楽】 【ヘルスケア】 【電子書籍】
    【生活情報】 【エンタメ】

    View full-size slide

  3. .
    Operation System
    3
    エムティーアイとAzureの歴史
    Windows Serverと
    RHELが混在
    Web Server
    殆どがASP (.NET)と
    Javaアプリケーション
    Middleware
    MySQLやPostgreSQLは
    殆ど採用されなかった
    Azure化以前

    View full-size slide

  4. .
    Cloud Service WebRole
    4
    エムティーアイとAzureの歴史
    主要機能を.NET MVC
    アプリケーションに置き換え
    クラウド化のためにJavaをC#に移行
    クラウド移行
    iRuleを必須とするアプリ
    主にガラケーコンテンツで
    User-Agent毎の細かい制御が必要
    オンプレ残留
    Tomcat・Java実装群
    サービス単位で作り変えの工数
    が多すぎると判断されたもの
    ミッションクリティカルなDB
    クラウド化検討時、
    SQL Azureが現在ほど安定
    しておらず、ひと月に
    1~2回はダウンが発生していた
    (平均30秒、最大60秒程度)
    BLOB
    静的コンテンツ
    PaaS Diagnostics
    Table Storage
    トークン情報や
    パフォーマンスカウンタ
    SQL Azure
    SQL Server Onpremise
    からの移行

    View full-size slide

  5. .
    検索してみた
    5
    Mackerel + Azureって…
    (;´Д`)

    View full-size slide

  6. .
    6
    AWSだとできるのに
    Azureインテグレーション
    ( ゚Д゚)ホスィ・・・
    ※ただしAWSに限る

    View full-size slide

  7. .
    7
    AWSだとできるのに
    ※ただしAWSに限る

    View full-size slide

  8. .
    8
    AWSだとできるのに
    ※ただしAWSに限る

    View full-size slide

  9. .
    9
    それでもMackerelを選ぶ
    インフラの
    ヘテロ化
    サービスの
    マイクロ化
    従来ツール群
    の限界
    アジャイルの浸透とリリース
    サイクルの高速化で、
    クラウドサービスが乱立
    開発者が使いたいツールが
    選択されていくことで
    利用サービスが分散
    設計の多様化でニーズに
    合致した運用サービスが提
    供できていない
    性能低下やFaultをただ通知するだけでなく
    多様化する環境を俯瞰的に管理することができる
    クラウドパフォーマンス管理ツールが必要になった

    View full-size slide

  10. .
    管理概念が運用設計に委ねられている
    10
    サービス?ロール?
    ルナルナ
    サイト
    ルナルナ
    アプリ
    ルナルナ
    プラット
    フォーム
    WEB Proxy
    Auth
    API RDB
    サービス
    ロール

    View full-size slide

  11. .
    ServiceDefinition.cscfgをゴニョる
    デプロイのWindows Serverプロビジョニング段階で
    インストーラーが起動するようにプロジェクトを構成
    11
    クラウドサービスへの導入
    サービス構成分離の対応
    非商用環境でも検証するために
    ビルド構成に応じてインストール
    の要否とロードするconfigを変更
    Workerロールのログ監視
    log-checkプラグインを使用して
    アプリケーションログを監視
    (公式バンドルされるよりも以前に
    公式プラグインを自前ビルドして
    使用)

    View full-size slide

  12. .
    AUTO_RETIREMENT=1が効かない!
    Windows環境ではmackerel-agent.confで
    使えない(動作しない)設定があることがわかる
    12
    Scale-In・Reconfigurationで
    /usr/local/bin/mkr retire --force $(/usr/local/bin/mkr alerts
    |jq '.[] |select(.monitorId == "$monitorid")' |jq -r .hostId)
    CLIツールmkrでロールアウトしたインスタンスを
    退役させることで(半強制的にこの問題を)解決

    View full-size slide

  13. .
    Mackerelエージェントが入れられない
    マネージドリソースをどう管理するか?
    13
    ホスト化できないリソース
    (Mackerelにとっての)
    プロジェクト全体で参照すべき
    指数系メトリックを
    サービスメトリックとして定義
    単一リソースに関連づく
    パフォーマンス系メトリックを
    ホストメトリックとして定義
    SQLCMD + Invoke-RestMethod

    View full-size slide

  14. .
    一覧性をよくするため
    カスタムダッシュボードを作成
    14
    SQL Azure DTU見える化

    View full-size slide

  15. .
    ロール内で起きている異常がわかる
    標準メトリック:個々の平均値しかわからず、時間粒度が粗い。
    相関で見れるようにするためにダッシュボード作成に手間がかかる
    ※リソースがサブスクリプションや認証ディレクトリで分割されておりApplication Insights化を検討したが断念
    15
    感じた導入効果
    iowaitが一定のインスタンスに偏っ
    て高くなる現象
    →処理ロジックの見直しが必要、
    という判断材料に
    可用性グループ内の
    平均値では顕在化しない

    View full-size slide

  16. .
    16
    感じた導入効果
    タイムリーに問題分析できる
    メトリックが一箇所に固まっているため、リージョンや依存関係の
    あるシステム起因で起きている問題なのかどうかがひと目でわかる
    グラフアノテーションで相関分析できる
    サービスメトリックにアノテーションを付与しておくことで、
    担当外のメンバーもその時間に何があったかがわかり、
    リリース後の変化やボトルネックの特定がしやすくなった

    View full-size slide

  17. .
    外形監視が使いやすい
    WebアプリでもREST APIでも、レスポンスタイムがすぐとれる。
    リクエストヘッダ・レスポンス検査・SSL証明書期間確認など、
    必要な機能を抑えている
    17
    感じた導入効果
    開発も運用も同じところを向くようになる
    サイトパフォーマンス管理は運用任せではなく自分ごとの意識が浸透
    現在オーガニゼーション参加メンバーの9割が開発者

    View full-size slide

  18. .
    魔改造ではなく現実的な取り組みとして
     Cloud ServiceのROLEINSTANCEIDをホスト情報に
     Mackerelアラート起点のWebHook自動スケール
     AppService・App Service Planのメトリックをとる
     Redis Cacheのメトリックをとる
     ゆくゆくはコストコントロールも
    18
    エムティーアイとしてのバックログ

    View full-size slide

  19. .
    エムティーアイでは中途採用エンジニア
    を募集しております!
    19
    さいごに

    View full-size slide

  20. .
    20
    免責事項:
    ・当発表資料は株式会社エムティーアイ(以下、当社)の
    意見を代表するものではありません。
    ・本資料内に記述された参考情報の正確性、技術的裏付けは発表者の経験則に
    基づくものであり、真実性に関して一切保証しておりません。
    ・資料内の情報を実環境で実施したことによって発生した間接的・偶発的・その他
    いかなる損害に関しても当社は一切の責任を負いません

    View full-size slide