Mackerel ブログ #mackerelio

Mackerelの公式ブログです

mackerel-check-plugins v0.22.1 で入った、check-log への変更について

こんにちは。Mackerelチーム CRE の井上(id:a-know)です。

昨日、同じくCREの三浦(id:missasan)より、Mackerelのアップデート告知をお知らせしましたが、その中で以下のようなアップデートが含まれていたかと思います。

go-check-plugins v0.22.1 のリリースで、check-log プラグインでログファイルを追尾する際にinode番号を参照するよう変更しました。 これによりログローテーションされた際のログファイルの追尾精度が向上しました。

今日のこのブログ記事では、その変更内容について少し詳細に解説したいと思います。

当記事の要約

check-log のチェック対象ログファイルの追跡を、これまでの「ファイル名のみ」に加えてinode番号も加味して追跡するようにしたことで、追尾可能なケースを増やしました。

従来までの check-log プラグインのおおまかな仕様と、その課題

Mackerel(mackerel-agent)には、チェック監視をおこなう仕組みがあります。

mackerel.io

command で指定したコマンドを実行したその終了ステータスにより、WARNING CRITICAL UNKNOWN アラートを発報させることができます。通常、このチェック処理は毎分実行されます(check_interval オプションを指定することで実行間隔を指定可能)。そして、このチェック監視に便利に使っていただけるものとして、公式として用意しているプラグイン集が mackerel-check-plugins であり、check-log プラグインもこれに含まれる形となります。

そして、check-log の仕様をおおまかに書くと、以下のようなものとなっていました。

  • check-log によるチェック対象のファイルは、--file オプションなどで指定する
  • チェック完了した位置(バイト数)をstateファイルとして出力しておく
    • stateファイルは「チェック対象のファイル」と「check-log コマンドに渡している引数」毎に作成され、管理される(該当ソースコード
  • 前回チェック時以降の出力差分に対して、チェックを実施する
    • stateファイルに記録されているバイト数分、読み飛ばすことで実現しています。
    • stateファイルに記録されているバイト数よりも読み込み対象ファイルのバイト数が小さければ、ログローテーションが発生したとみなして先頭から読み直すようにもなっています。

「stateファイルに記録されているバイト数よりも読み込み対象ファイルのバイト数が小さければ、ログローテーションが発生したとみなして先頭から読み直す」という作りにはなっているものの、ログの出力とログローテーションのタイミングによっては、チェック対象から漏れてしまうログ出力行が発生し得ます。例えば以下のようなケースです。

  • 12時00分00秒:ログチェック処理実施
  • 12時00分10秒:ログ出力(※1)
  • 12時00分20秒:ログローテーション発生
    • これまで出力していたファイルの名前を変更し(production.log → production_yyyyMMdd.log など)、新たにファイルを作成する(いわゆる copytruncate ではないログのローテーション)
  • 12時00分30秒:ログ出力(※2)
  • 12時01分00秒:ログチェック処理実施

上記のようなケースでは、※2の部分で出力されるログに関してはきちんとチェック対象となるものの、※1の部分で出力されるログについてはチェック対象から外れてしまいます。従来までの check-log には、このような課題がありました。

今回 check-log に対しておこなった変更について

上記のような課題に対して、今回以下の2つの Pull Request によって対処をおこなっています。

この2つについて、以下で掘り下げてみたいと思います。

[check-log] Jsonize status file

この Pull Request によって、stateファイルの構造をJSON形式に変更しています。それまでは、読み込み済みのバイト数だけが出力されたフラットな形式でした。

Mackerel では常に互換性を意識して開発を進めているため、今回のこの変更も「まずJSON形式のstateファイルの有無をチェックし、あればそれを用いて読み込み済みバイト数情報を取得。JSON形式のファイルがなければ、以前の形式のstateファイルを読み込む」という挙動となるように実施しており、これまでの check-log を使っている環境でも問題なく利用できるようにしています。

[check-log] Trace an old file after logrotation with the inode number

上で説明した課題への対策としては、この Pull Request がメインとなります。内容の概要としては、以下の通りです。

  • stateファイルに、チェック対象ログファイルの inode 番号も常に保存するようにする
    • これを実施したいがためのJSON形式への構造変更、というわけですね。
  • 「ログローテーションが発生していないか否か」を、「stateファイルに保存されたinode番号とファイルパスで指定されるファイルのもつinode番号の一致」を確認する形で、毎回実施する
    • ログファイルのinode変更を検知して、ローテーションされたファイルをinode番号で特定し、そのファイル末尾までのチェックを実施します。

これら2つの Pull Request により、上述したようなログローテーション時の課題に対して対処できるようになりました。

今回の変更に関する注意点について

ただし、注意点もあります。以下のような事柄です。

  • logrotate でいうところの copytruncate 方式のログローテーションには対応していません。
    • ローテーション時にログファイル自身のコピーをおこない、ログファイルのリセットを行う場合、ログファイル自身のinode番号は変わらないため。
  • 一時的にチェック対象スコープから外す意図でファイル名を変更した場合でも、inode番号により追跡されます(チェック対象から外すことはできません)。
  • ローテーション検知時の古い方のファイルのinode番号による追跡は、元のログファイルと同一ディレクトリ内に限ります。
  • 現時点では、Windows環境には対応していません。
    • ただし、stateファイルがJSON形式となったことで、inode番号以外のファイル識別子を保持することはこれまでよりも容易になりました。

まとめ

mackerel-check-plugins v0.22.1 で入った、check-log への変更内容についてご紹介しました。ここで紹介した Pull Request が閲覧できることでもわかるとおり、Mackerel のプラグイン、エージェントなどは OSS になっています。これらの公式リポジトリについては、もちろん今後も私たち Mackerel チームが責任を持って開発・メンテナンスをおこなっていきますが、Mackerelをご利用の皆さんからの Pull Request・issue起案なども歓迎しています!

GitHub リポジトリでのコミュニケーションについては基本的に英語でお願いをしているのですが、以下の Mackerel Users Group のslackチームには Mackerel の開発エンジニアも参加しており、ここでは日本語でコミュニケーションをすることが可能です。

slackin - Mackerel UG slack チームに参加する

「こういう Pull Request を送ろうと思っているのだけど、ちょっと自信がない......」、そういった場合でもお気軽に相談していただけますので、ぜひこちらへのご参加もご検討ください!

システムメトリックに loadavg1、loadavg15 を追加しました ほか

こんにちは。Mackerelチーム CRE の三浦(id:missasan)です。

週末はISUCON8が開催されていましたが、Mackerelチームの松木(id:Songmu)と柴崎(id:id:shiba_yu36)がみごと予選を突破しました。本戦が楽しみですね。

それでは、最新のアップデート情報です。

システムメトリックに loadavg1、loadavg15 を追加しました

mackerel-agent v0.57.0 のリリースにより、これまで loadavg5 のみ対応していたloadavgグラフに loadavg1loadavg15 を追加しました。 loadavg5loadavg15 を比較して、CPU負荷が増加しているか減少しているかを確認する際に便利です。 mackere-agentを最新版にアップデートすると、対象のホストにてシステムメトリックが2項目追加されます。

この変更は Windows Server 以外のすべてのプラットフォームに対応しています。

f:id:mackerelio:20180918122511p:plain

check-log プラグインでログローテーションの追尾精度が向上しました

go-check-plugins v0.22.1 のリリースで、check-log プラグインでログファイルを追尾する際にinode番号を参照するよう変更しました。 これによりログローテーションされた際のログファイルの追尾精度が向上しました。

check-http で辿るリダイレクトの数を指定できるようになりました

go-check-plugins v0.22.1 のリリースで、オプション --max-redirects にて、辿るリダイレクトの数を指定できるようになりました(デフォルト値は 10 です)。

コントリビュートいただき、ありがとうございました!

AWS ALB、ELB の RequestCount メトリックが null の場合に0を投稿するように変更しました

AWSインテグレーション機能で ALB、ELB のメトリックを取得している環境で、CloudWatch から取得した RequestCount メトリックの値が null だった場合に、0 を投稿するように変更しました。 これにより、値が null であることにより発生していた、アラートが自動でクローズされないという問題が改善されました。

Windows Server 用インストーラのコードサイニング証明書を更新しました

mackerel-agent v0.57.0 のリリースにて、Windows Server 用インストーラのコードサイニング証明書を更新しました。 以前のバージョンのインストーラを利用した場合は、証明書の期限切れが警告されますので、ご注意ください。

【サマーインターン生リリース機能一挙公開!】オーガニゼーション一覧画面を追加しました ほか

こんにちは。Mackerelチーム CRE の三浦(id:missasan)です。

今日は、早いもので1ヶ月あった はてなサマーインターン2018 の最終日です。

developer.hatenastaff.com

はてなのサマーインターンでは、期間の後半はインターン生が各チームに配属されて、実際にサービスに組み込まれる機能開発や業務の課題に取り組みます。 Mackerelチームにも2名のインターン生が配属されて、たくさんのタスクに挑戦してくれました。

先日の9/3(月)にご紹介した「API からロールの登録・削除が可能になりました」という箇所もインターン生が実装しリリースされた機能です。

mackerel.io

サマーインターン最終日ということもあり、今日はインターン生が実装した機能一式をどーんとご紹介します。

インターン生をそばで見守っていたMackerelディレクター 粕谷(id:daiksy)からのメッセージです。

Mackerelチームでインターン生を受け入れるのは今年で4回目になります。 今年も例年に負けずにものすごいスピードで開発が進み、会議が終わってGitHubを見ると「え!?この機能もうレビュー依頼になってるの??」と驚く場面がこの期間中何度もありました。

2週間のチームでの開発を終え、今日が今年のインターン最終日です。 インターン生にとっても良い経験になったかと思いますが、我々も同じくらい刺激を受けることができ、とても充実した2週間でした。

ジョインしてからたったこれだけの期間で、これだけたくさんの機能が開発・リリースされるというのは、ほんとうに驚きの2週間でした。

それでは、アップデート情報です。

オーガニゼーション一覧画面を追加しました

以下URLにアクセスすると、自分が所属するオーガニゼーションの一覧を見ることができます。

https://mackerel.io/orgs/

左サイドメニューにて、[オーガニゼーション名]横の[▼]をクリックし、[Organizations]をクリックいただいても同じ画面を見ることができます。

各オーガニゼーションのサービス数、ホスト数、メンバー数、現在発生しているアラート数なども表示されます。 複数のオーガニゼーションに所属している場合に、どのオーガニゼーションでアラートが発生しているかなど全体を俯瞰して確認したいときにお使いいただけます。

サービス・ロールに対してメタデータを投稿できるAPIを追加しました

これまでホストに対してメタデータを登録できましたが、今回の改修により、サービス・ロールに任意の JSON データをメタデータとして登録できるようになりました。 詳細は Mackerel API ドキュメント メタデータ をご覧ください。

IDを指定して監視設定を取得する API を追加しました

対象の監視設定IDを指定して、設定情報を取得できるAPIを追加しました。 指定方法は /api/v0/monitors/<monitorId> です。

詳細は Mackerel API 監視設定 をご覧ください。

通知チャンネルを登録・削除するAPIを追加しました

このAPIは メール通知 と Slack にのみ対応しています。 またこの改修と合わせ、チャンネル一覧取得 API で取得できる情報が、メール通知と Slack の場合はより詳細に取得できるようになりました。

詳細は Mackerel API ドキュメント 通知チャンネル をご覧ください。

アラート一覧画面の絞り込みで複数サービスを選択できるようになりました

アラート一覧画面で、表示するアラートを絞り込む際に、複数のサービスを OR で指定できるようになりました。

f:id:mackerelio:20180907104350p:plain

ホスト一覧画面の絞り込みで複数サービスを選択できるようになりました

アラート一覧と同様、ホスト一覧画面で表示を絞り込む際に、複数のサービスを OR で指定できるようになりました。

f:id:mackerelio:20180907111012p:plain

インターン生のみなさんお疲れ様でした!

AWSインテグレーションによるEC2連携ホストの自動退役機能を追加しました ほか

こんにちは。Mackerelチーム CRE の三浦(id:missasan)です。

今回は、多くのユーザの方々からご要望があったタイトルの機能以外にも、はてなサマーインターン生による追加機能、コントリビューターの方による追加・改善など盛りだくさんの内容です。 ぜひ詳細までお読みください。

それでは、アップデート情報です。

AWSインテグレーションによるEC2連携ホストの自動退役機能を追加しました

AWSインテグレーション機能で連携したEC2ホストを、自動退役できる機能を追加しました。 この機能を有効にすると、インスタンスの削除を行った際に、Mackerel上で自動で退役処理が実行されます。 設定方法は、AWSインテグレーション設定画面にて 自動退役を有効にする にチェックを入れてください。 すでに登録されているAWSインテグレーションの設定では、無効となっています。新規に登録される場合は、デフォルトで有効となります。

f:id:mackerelio:20180903132621p:plain

EC2 にのみ設定可能な機能ですので、それ以外のAWSサービスを合わせてご利用の場合は、ご注意ください。

API からロールの登録・削除が可能になりました

APIからロールの登録・削除が行えるようになりました。詳細は以下をご覧ください。

mackerel.io

この機能は、Mackerel開発チームのエンジニアの指導の下、はてなサマーインターン2018に参加しているインターン生が開発した追加機能です! インターン生の中では最速のリリースでした。

developer.hatenastaff.com

Mackerel が公式に提供している golang client である mackerel-client-go も対応しています。

アラートグループの通知にアラート詳細情報を追加しました

Slackなどに投稿される通知内容に、アラートグループに含まれる一部詳細情報が表示されるようになりました。 グループ内の最大3件のアラート詳細が表示されます。 ぜひ通知をオンにして、表示を確認してみてください。

アラートグループはまだまだ新しい機能なので、使い勝手についてのフィードバックやご要望などもぜひお寄せください。

mackerel.io

mackerel-plugin-postgres にて AWS Aurora PostgreSQL が監視できるようになりました

mackerel-agent-plugins v0.51.1 のリリースにて、mackerel-plugin-postgres にて AWS Aurora PostgreSQL をサポートしました。

github.com

check-smtpを追加しました

go-check-plugins v0.22.0 のリリースにて、check-smtp を追加しました。 check-tcpでも smtp の接続を確認する機能がありますが、より smtp に特化した機能となっています。

github.com

Pull Request をくださったコントリビューターのみなさま、ありがとうございました!

メトリックのインクリメンタルサーチの速度が向上しました ほか

こんにちは。Mackerelチーム CRE の三浦(id:missasan)です。

アップデート情報です。

メトリックのインクリメンタルサーチの速度が向上しました

監視ルール設定の詳細設定画面で [監視対象] - [メトリック] のテキストボックスにキーワードを入力すると、すべてのメトリックから監視ルールに利用したい該当のメトリックを検索することができます。今回の改修によって、その検索速度が大幅に改善されました。この改善は7/18(水)データベースメンテナンスによって実現が可能になったものです。

f:id:mackerelio:20180820114146p:plain

itamae-plugin-recipe-mackerel-agent にて plugin-registry のプラグインを自動インストール可能になりました

itamae-plugin-recipe-mackerel-agent において、 plugin-registry のプラグインを自動的にインストールすることが可能になりました。 この機能の利用にはmkrコマンドのインストールが必要となります。

github.com

itamae-plugin-recipe-mackerel-agent は、itamae で mackerel-agent をインストールするためのレシピを gem としてリリースしたものです。 itamae を使って mackerel-agent のインストールがより手軽になります。

plugin-registry はユーザが作成した便利なプラグインが登録された公式プラグインレジストリです。プラグインレジストリに登録されたプラグインは、mkr plugin install <plugin_name> という形式でインストールできます。

【お知らせ】お盆期間中におけるサポート窓口対応休業について & メールシステムメンテナンスについて

いつもMackerelをご利用いただきありがとうございます。

お盆期間中におけるサポート窓口対応休業について

以前の告知でも事前にお知らせさせていただいていましたが、

mackerel.io

Mackerel公式サポート窓口対応(Mackerel にログインしている状態でヘッダー右上に表示されている「サポートチームへ連絡」からのお問い合わせや、support@mackerel.io 宛へのお問い合わせ対応)について、以下のお盆期間中はお休みをさせていただきます。

お盆休業期間:2018年8月13日(月)〜 2018年8月15日(水)

この期間中にいただいたお問い合わせについては、2018年8月16日(木)以降に順次対応させていただきます。ご理解のほど、どうぞよろしくお願いいたします。

2018年8月14日(火) メールシステムのメンテナンスのお知らせ

こちらも先日お知らせした通りですが、2018年8月14日(火)、Mackerelが利用しているメールシステムにおいてメンテナンスが予定されています。

詳細は以下のエントリーをご確認ください。

mackerel.io

Mackerel Meetup #12 Tokyo を開催しました & 開催レポート!

こんにちは! Mackerelチーム CREの井上(id:a-know)です。こちらのブログではお久しぶりとなります。

さて今回は、昨日・8月2日(木)に開催した Mackerel の公式イベント、Mackerel Meetup #12 Tokyoの開催レポートをお届けします! 公式ミートアップとしては、前回から約半年ぶりの開催となりました。参加できた方も、そうでない方も、ぜひこちらのレポートで会場の雰囲気を味わっていただけたら、と思います!

開催会場はドリコム様のセミナースペース & カフェスペース!

f:id:mackerelio:20180803155714j:plain

Mackerel Meetup の第12回会場となる場所をお借りさせていただいたのは、Mackerelのユーザーさまでもある株式会社ドリコム様!

f:id:mackerelio:20180803154646j:plain

ミートアップを開催する度に思うのですが、毎回このような素敵な会場をお借りすることができて、本当にありがたい限りです......!

f:id:mackerelio:20180803154132j:plain

受付の様子。クリアファイル・扇子など、Mackerelオリジナルのノベルティグッズをたくさん並べて、みなさんをお出迎えです。

f:id:mackerelio:20180803155551j:plain

こちらはセッション終了後に懇親会会場となるカフェスペースの一角。積まれているボードゲームの数々に、思わず見惚れるはてな社員もいました。(笑)

f:id:mackerelio:20180803154218j:plain

こちらはセッション会場となるセミナースペース。否が応でも、これから始まる内容への期待が高まります。

素敵な会場をご提供くださったドリコムさま、本当にありがとうございました!

1stセッション『200週連続新機能リリースとこれから』

まず最初のセッションは、『200週連続新機能リリースとこれから』と題し、Mackerelのプロダクトマネージャーである松木(id:Songmu)からお話しさせていただきました。

松木自身の Mackerel との馴れ初めから始まり、まずは先日達成した200週連続機能リリースのダイジェストを紹介しました。 その後のユーザーの方からのお話しにもあったのですが、「ああ、あの便利な機能はこの年でのリリースだったのか」「毎週の積み重ねが今のMackerelがあるんだな」といった思いを、私も感じずにはいられませんでした。

その後、Mackerel のプロダクトの一部はOSS(オープンソースソフトウェア)であること、歴代の便利な機能群の一部は実はMackerelユーザーの方々の contribute(GitHubリポジトリへの Pull Request 等)によるものであること、などを紹介することで、「Mackerelはこれまでも・これからも、我々だけでなくユーザーと一緒に作り上げるもの」であることを熱弁。200週連続リリースと今後のアップデートを支えるもののひとつに、Mackerelユーザーのみなさんからのご意見や貢献が不可欠であることをお伝えさせていただきました。

f:id:mackerelio:20180803154310j:plain

そして、最も注目度の高かった2018年の開発ロードマップの進捗状況について。既にリリース済み機能である『アラートグループ』をはじめとして、『コンテナ正式サポート』『カスタムダッシュボードv2』『異常検知』といった開発中の機能についても、その開発状況をスクリーンショットも交えつつご紹介しました。いずれも「クリスマスまでにはリリースします!」(松木)として会場の笑いを誘っていましたが、気になる方はぜひ、発表資料をご確認ください!

2ndセッション『機械学習を用いたMackerelの異常検知機能について』

続いてのセッションも、はてな社員からの発表。先の松木からの発表内でも期待値を高められていた Mackerel 待望の新機能、『異常検知』機能についてのその機能の成り立ちやアルゴリズムについてのお話しを、はてなのアプリケーションエンジニアである吉田(id:syou6162)から。

f:id:mackerelio:20180803154509j:plain

「そもそも、サーバーの監視で困ること、ってなんでしょうか」という問題提起からお話は始まります。サーバー監視の困りごと、それは、

  • サーバー監視初心者にとっては「どういう状態が異常であるのかがよくわからない」
  • サーバー監視上級者にとっては「知識や経験はあるものの、得てして監視対象範囲が広く、多忙であり、全てを見きれなくなってしまう」

といったことがある、とご紹介。私も普段、毎日のようにいろんなお客さまと会話をしますが、現場の担当者の方にとって上記の2点は本当に悩みのタネであることを実感しています。そして、そんな方々を助けるために『異常検知』機能を作ったよ、と吉田。既にはてな社内での限定リリースを実施しているこの機能を用いて、実際に社内であった事例の紹介を交えつつ、「サービス」「ロール」に当てはめてサーバー群を管理するそのメリットも実感させてくれる発表でした。

f:id:mackerelio:20180803154446j:plain

発表の後半は、そのアルゴリズムについての解説でした。私も一番うしろから見ていたのですが、食い入るように発表を聞いているみなさんの様子には、さすがエンジニア!と思わされました。

発表に用いたスライドは以下になります。ぜひご覧ください!

www.slideshare.net

3rdセッション『トレタのインフラ運用を支えるMackerel』

ここからは、Mackerelユーザーの方からの発表になります。まずは、株式会社トレタでインフラエンジニアをされている、山田さんからの発表。

f:id:mackerelio:20180803154731j:plain

www.slideshare.net

トレタさま自身のご紹介をしていただいたあとに、トレタでの進んだデプロイ・プロビジョニングフローと、そのフローにどうMackerelを活用しているか、といったところについてお話しいただきました。Ansible / Packer / Terraform など、各種自動化ツールを駆使して日々の業務を極力効率化されている様子がよくわかりました。

そしてその次に、『最近まで知らなかったけれど、使ってみたらとても便利だった機能』として、以下のような機能の活用について、実例も交えつつお話しいただきました。

  • カスタムダッシュボード
  • グラフアノテーション
  • AWSインテグレーション

特に、「これらの機能を活用することで、非エンジニア・営業の方々も同じグラフを見られるようになり、コミュニケーションが取れるようになった」というお話しには、私もとても感動してしまいました。サービス提供者冥利につきる良いエピソードをお聞かせいただきました。トレタの山田さん、本当にありがとうございました!

4thセッション『フルマネージドホスティングの運用監視にMackerelを導入した話』

Mackerel Meetup #12 Tokyo のトリを飾るのは、アイテック阪急阪神株式会社 主事の森本さんからの発表。

f:id:mackerelio:20180803154819j:plain

アイテック阪急阪神さまでは、自社基盤を中心としたアーキテクチャで法人向けフルマネージドホスティングサービスを展開されていて、今回はその基盤へのMackerelの導入についてお話しいただきました。

それまでの課題として、以下のような問題を抱えていた、と、森本さん。

  • ユーザーへの障害通知にタイムラグがあった
  • 監視システムが混在していた
  • 監視設定の間違いが度々発生していた
  • 監視サーバーに設計上の問題があった

そして、ある日起きてしまった大規模なネットワーク障害を機に、これらの課題を総合的に解決する手段として Mackerel の導入を決断された、とのことでした。

真に迫る発表内容に、聞いている方のなかにも「聞いているだけでお腹が痛くなる......」とのつぶやきが見受けられるほど。私たちも襟を正しながらも、そんな困難に直面している方の力に Mackerel がなれているということは嬉しくもありました。

また、法人向けフルマネージドホスティングサービスを提供されている方ならではの、工夫していただいている点についてもお話しいただきました。これについてはMackerelチームメンバーも大変興味深く拝見しており、「公式の機能として提供できないか」といった議論も早速生まれています。こうしたところも、「ユーザーと作る」ということの一面なのかなと思っています、ぜひこれを読んでいるみなさんも多くのご意見をお寄せください!

アイテック阪急阪神株式会社の森本さん、貴重なお話しをありがとうございました!

セッションの後は懇親会!

ためになるお話しのあとは、冒頭でもご紹介したカフェスペースでの懇親会!

f:id:mackerelio:20180803160317j:plain

本編に引き続き、たいへん多くの方にご参加いただきました!こうしてユーザーの方同士での交流の場としての機会も提供できること、大変うれしく思います。

会の後半には、Mackerel公式アパレルグッズ大放出のじゃんけん大会も!

f:id:mackerelio:20180803155305j:plain

おそらくこれまでのミートアップのなかでも一番多くの方にグッズをお渡しできたのではないかと思います!今後もMackerelチームは、新機能だけでなく新グッズもどんどん作っていきますので、お楽しみに!

f:id:mackerelio:20180803160124j:plain

本当に素敵な時間を過ごさせていただきました。会場をご提供いただいたドリコムさま、登壇いただいた山田さん、森本さん、そしてご来場いただいたみなさま、本当にありがとうございました!