Mackerel MeetUp #10用発表資料

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

Transcript

1. . で支えるエムティーアイの ヘルスケアプラットフォーム MTI Ltd. N.akama @mdadm
2. . 2 弊社サービスのご紹介 【音楽】 【ヘルスケア】 【電子書籍】 【生活情報】 【エンタメ】
3. . Operation System 3 エムティーアイとAzureの歴史 Windows Serverと RHELが混在 Web Server 殆どがASP (.NET)と Javaアプリケーション Middleware MySQLやPostgreSQLは 殆ど採用されなかった Azure化以前
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 からの移行
5. . 検索してみた 5 Mackerel + Azureって… (;´Д｀)
6. . 6 AWSだとできるのに Azureインテグレーション ( ﾟДﾟ)ﾎｽｨ･･･ ※ただしAWSに限る
7. . 7 AWSだとできるのに ※ただしAWSに限る
8. . 8 AWSだとできるのに ※ただしAWSに限る
9. . 9 それでもMackerelを選ぶ インフラの ヘテロ化 サービスの マイクロ化 従来ツール群 の限界 アジャイルの浸透とリリース サイクルの高速化で、 クラウドサービスが乱立 開発者が使いたいツールが 選択されていくことで 利用サービスが分散 設計の多様化でニーズに 合致した運用サービスが提 供できていない 性能低下やFaultをただ通知するだけでなく 多様化する環境を俯瞰的に管理することができる クラウドパフォーマンス管理ツールが必要になった
10. . 管理概念が運用設計に委ねられている 10 サービス？ロール？ ルナルナ サイト ルナルナ アプリ ルナルナ プラット フォーム WEB Proxy Auth API RDB サービス ロール
11. . ServiceDefinition.cscfgをゴニョる デプロイのWindows Serverプロビジョニング段階で インストーラーが起動するようにプロジェクトを構成 11 クラウドサービスへの導入 サービス構成分離の対応 非商用環境でも検証するために ビルド構成に応じてインストール の要否とロードするconfigを変更 Workerロールのログ監視 log-checkプラグインを使用して アプリケーションログを監視 (公式バンドルされるよりも以前に 公式プラグインを自前ビルドして 使用)
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でロールアウトしたインスタンスを 退役させることで(半強制的にこの問題を)解決
13. . Mackerelエージェントが入れられない マネージドリソースをどう管理するか？ 13 ホスト化できないリソース (Mackerelにとっての) プロジェクト全体で参照すべき 指数系メトリックを サービスメトリックとして定義 単一リソースに関連づく パフォーマンス系メトリックを ホストメトリックとして定義 SQLCMD + Invoke-RestMethod
14. . 一覧性をよくするため カスタムダッシュボードを作成 14 SQL Azure DTU見える化
15. . ロール内で起きている異常がわかる 標準メトリック：個々の平均値しかわからず、時間粒度が粗い。 相関で見れるようにするためにダッシュボード作成に手間がかかる ※リソースがサブスクリプションや認証ディレクトリで分割されておりApplication Insights化を検討したが断念 15 感じた導入効果 iowaitが一定のインスタンスに偏っ て高くなる現象 →処理ロジックの見直しが必要、 という判断材料に 可用性グループ内の 平均値では顕在化しない
16. . 16 感じた導入効果 タイムリーに問題分析できる メトリックが一箇所に固まっているため、リージョンや依存関係の あるシステム起因で起きている問題なのかどうかがひと目でわかる グラフアノテーションで相関分析できる サービスメトリックにアノテーションを付与しておくことで、 担当外のメンバーもその時間に何があったかがわかり、 リリース後の変化やボトルネックの特定がしやすくなった
17. . 外形監視が使いやすい WebアプリでもREST APIでも、レスポンスタイムがすぐとれる。 リクエストヘッダ・レスポンス検査・SSL証明書期間確認など、 必要な機能を抑えている 17 感じた導入効果 開発も運用も同じところを向くようになる サイトパフォーマンス管理は運用任せではなく自分ごとの意識が浸透 現在オーガニゼーション参加メンバーの9割が開発者
18. . 魔改造ではなく現実的な取り組みとして  Cloud ServiceのROLEINSTANCEIDをホスト情報に  Mackerelアラート起点のWebHook自動スケール  AppService・App Service Planのメトリックをとる  Redis Cacheのメトリックをとる  ゆくゆくはコストコントロールも 18 エムティーアイとしてのバックログ
19. . エムティーアイでは中途採用エンジニア を募集しております！ 19 さいごに
20. . 20 免責事項： ・当発表資料は株式会社エムティーアイ(以下、当社)の 意見を代表するものではありません。 ・本資料内に記述された参考情報の正確性、技術的裏付けは発表者の経験則に 基づくものであり、真実性に関して一切保証しておりません。 ・資料内の情報を実環境で実施したことによって発生した間接的・偶発的・その他 いかなる損害に関しても当社は一切の責任を負いません