「さくらの夕べ in 京都」レポート 〜Mackerelと学生コミュニティとJANOGの話〜

公開日

さくらのナレッジ編集部の法林です。

1/22(水)に京都経済センターにて「さくらの夕べ in 京都」を開催しました。さくらの夕べは各地で開催していますが、京都での開催は2013年7月に開催した「第9回さくらの夕べin京都」以来、約11年半ぶりだったようです(当時のニュースリリース)。本イベントの模様をレポートします。

Mackerelを作る人、使う人

登壇者の大仲さん(左)、久保

2013年に開催した「第9回さくらの夕べin京都」のニュースリリースや当時のツイートまとめを読むと、当時はてなのCTOだった田中慎司さんをお招きして、当社の代表である田中邦裕と対談したという記録が残っています。そこで今回もはてなとコラボレーションしたいと思いセッションを企画しました。当社では自社サービスの監視などにはてなのサービスであるMackerelを使用しているのでこれをセッションのテーマに据え、はてなからMackerelの開発に携わる大仲能史さんをお招きしました。当社からはSRE業務に携わる久保達彦が登壇しました。

プラットフォームを作る、プラットフォームを変える

はじめに大仲さんからMackerelの開発についての話がありました。

Mackerelはシステムを監視・観測する可観測性プラットフォームで、サービス提供開始から今年で10周年になります。主な機能としては、メトリックの投稿/閲覧、アラートなどの各種通知、外形監視などがあり、近年は可観測性の観点からトレースやメトリックエクスプローラーといった機能が追加されています。

開発者視点でのMackerelの面白さとしては、はてなの他サービスがread中心(少数の人が投稿し多数の人が読む)であることに対して、Mackerelはwrite中心(botが毎分投稿し人間のアクセスは少ない)で、特性がまったく異なる点が挙げられます。また、一般的なRDBではなく時系列データベースを使用している点も特徴です。ちなみにMackerelの時系列データベースは自社開発したものを使用しています(参考記事)。

Mackerelはもともと社内ツールで、サーバを「鯖」と呼んだりするところから、英語で鯖を表すMackerelがサービス名となりました。自社で提供している多数のWebサービスを開発・運営する中で数千台のサーバシステムを管理する必要があり、そのためのツールとして開発されたのが起源です(参考ページ)。その後、社内のビジネスコンテストで優勝したことを契機にSaaSとしてリリースすることになり、一から作り直してサービス化しました。このときは200週(約4年)連続でリリースするなど開発に追われました(参考記事)。

Mackerel 200週連続機能リリース達成の記事 (出典)

そんなMackerelも10年続ける中で、世の中の変化に対応していく必要性が出てきました。特に近年では、SRE、Observability(O11y)、OpenTelemetry(OTel)といった考え方が普及してきています。OTelによる標準化や、個々のサーバを見るのではなくシステム全体の状況を見るO11yの考え方は大きな変化と言えるでしょう。それからはてなの社内にも変化がありました。特にMackerelがサービスとして軌道に乗ると、ユーザからの要望に応える機能の開発優先度が高くなり(売上の増加が期待できるため)、発想が現在のMackerelに縛られるという状況が生まれてきました。

こうした状況を打破するために、まず世の中の変化の先頭集団について行く人を社内に持ち、そういう人たちが社内向けのエバンジェリストになって世の中の変化を伝え、その変化に適応したサービスの改革を進めていこうとしています。その成果がサーバー監視ツールから可観測性プラットフォームへの進化で、10年を超えてさらに今後も進化を続けていくという話がありました。

IaC for Mackerel

続いてさくらインターネットにおけるMackerelの利用についての話が久保からありました。久保は「さくらのマニュアル」のインフラ管理やエンハンスドロードバランサの開発/運用などに携わっています。Mackerelは前職時代から使っていて利用歴は10年近くになるそうです。

さくらインターネットではMackerelを利用するにあたり、手動で設定するのではなく、Terraformを用いた自動化を行っています。上図が動作イメージです。GitHubでプルリクエスト(PR)を作成すると、それをトリガーにGitHub Actionsを使ってterraform planが実行されます。PRがマージされると自動的にterraform applyが実行され、Mackerelの設定が更新されます。仕組みを構築するためのツールもMackerel LabsのGitHubにて「Terraform provider for mackerel.io」として公開されています。

上図はMackerelのWebコンソールにて外形監視を追加するときの画面です。HTTPメソッドや監視対象のURL、アラートを発報する条件などを記入し、画面最下部のUpdateボタンを押すと設定が追加されます。

これに対してTerraformで監視を追加するときの作業を解説したのが上図です。左側がPRの画面で、Terraformの書式に則って監視対象やアラート条件などのコードを記述してPRを出します。右側がTerraformを実行している様子で、実行結果がGitHubのコメントとして追記されています。

Terraform化するMackerelのリソースは、ダッシュボード(mackerel_dashboard)、モニター(mackerel_monitor)、チャンネル(mackerel_channel)、通知グループ(mackerel_notification_group)、サービス(mackerel_service)などです。普段よく使うようなMackerelのリソースは概ねTerraformで記述することができます。ただ最初からTerraformで書こうとすると難しい場合もあるので、そういうときはいったん手動で設定してからTerraform化します。

Mackerelの設定をTerraform化する理由としては、既存のソフトウェア開発フローと同じやり方で設定を更新できる、変更の履歴を追跡しやすい、仕組みの構築には多少の手間がかかるが構築後の運用は非常に楽、といったところです。最後に課題として、Terraform未対応のリソースが結構あることや、契約がOrganization(Mackerelを利用する会社・組織・個人)単位で行うため、気軽にOrganizationを作成できないといった点を挙げました。

ディスカッション

ここからはディスカッションの時間です。筆者が事前に用意してきたお題を登壇者に投げかけて回答していただく形式で進行しました。

ユーザから開発者へ

筆者: 開発者に聞いてみたいことはありますか？
久保: DBのI/Oまわりはどうなっていますか？
大仲: DBへのリクエストが非常に多いので、多数のキューに溜めながら書き込むという処理をしています。その際にキューの流量を調整する必要があります。AWSのKinesis上にキューの仕組みを作っていますが、オートスケールを使わないようにするために、アクセスが少ないときはダミーのリクエストを発行してキューの数を維持しています。
久保: Terraform Providerの開発体制はどうなっていますか？
大仲: 専任のチームは置いていません。ただ最新技術に追随するような努力はしています。

開発者からユーザへ

筆者: ユーザからの声はたくさん届くんですか？
大仲: Mackerelはユーザ向けのイベントを多数開催しているので、ユーザからの声はたくさん受け取っています。自社イベントとしてはDrinkUpを毎月やってました。技術コミュニティ主催のイベントに出向くこともよくあります。
久保: そういえば以前に、Mackerelのフィードバック画面から機能追加の要望を送ったら程なく実装されていて、すげー！と思ったことがあります。
筆者: 開発者からユーザに要望を聞くようなこともありますか？
大仲: Mackerelでもカスタマーリライアビリティエンジニア(CRE)という職種があり、大手の顧客に対してはそういった人たちが対応しています。一般ユーザからの要望はフィードバックのメールなどを見て対応しています。

監視や可観測性について思うこと

筆者: 久保さんが入社した時点(2023年)から、オブザーバビリティなどの取り組みはどれぐらい進みましたか？
久保: まだ発展途上の段階ですね。先ほど発表したTerraformを使った仕組みなどもその一環として構築したものです。オブザーバビリティのカバーする範囲ってかなり広いので、やることはまだまだたくさんあります。

筆者: 大仲さんは監視関連の変化をどのように感じていますか？
大仲: 技術の変化という意味では、かつてはCPU使用率などの値を見ていました。でもそれだけではアプリケーションがエラーなのかエラーではないのかわからないので、そういったものは別物で監視していかないといけないという考え方に変わってきたのが近年の流れですね。
久保: Zabbixなどでもいろいろな監視ができますが、今はアプリケーションの監視をするための道具がそろってきたので敷居が下がってきましたね。DevOpsという言葉がありますが、今は開発者がインフラの監視も含めて面倒を見るという形に変化してきていると思います。

筆者: さくらインターネットのサービスの開発や運用も変わってきていますか？
久保: それを変えていくのがSRE室のミッションのひとつなので、考え方を伝えるところも含めてやっているところです。

その他

参加者からも質問を受け付けて、以下のような質疑応答がありました。

質疑応答の様子
  • クラウドを使うとクラウドベンダーの仕組みに縛られて外部の監視システムを入れにくくならないか？
    → 標準化の仕組みを利用することでマルチクラウド利用時にはむしろ外部の監視システムを利用する価値が高まる
  • 長年同じプロダクトをやっていると新しいことをやるモチベーションが下がってしまう問題を抱えているがどうやって対策しているか
    → 挑戦することを評価軸の1つにする/開発合宿を定期的に実施し日頃の業務と関係なく作ってもらう/社員の行動指針に自発的な行動を掲げる
  • Webブラウザの操作などユーザ体験を監視することはできるか
    → Mackerel以外のツールで監視できるのでそれをOTelで取り込むことは可能
  • さくらでMackerelを使っている理由は何か
    → 自社サービスは社外から監視した方がよい

また、誌面の都合で割愛しましたが、大仲さんからは最近リリースもしくは開発中のMackerelの新機能に関する話もありました。リリースされたものについてはMackerelのウェブサイトに掲載されているリリース情報をご覧ください。

「京都といえばはてな」という単純な発想で企画したセッションでしたが、長年開発しているサービスならではの課題やその解決方法(これは当社のサービスにも通じる話です)、当社のインフラもソフトウェア開発的な手法が取り入れられていることなど、いろいろなことをお伝えできたと思います。大仲さんをはじめはてなの皆さん、ご協力ありがとうございました。

さくらインターネットは関西の学生コミュニティを応援します！

登壇者の上田さん、丸谷さん (左から)

さくらインターネットは学生コミュニティが主催するイベントに協賛したり、行事で使用するシステムを構築するのに必要なサーバなどを支援するといった活動を行っています。本イベントではこれらの支援活動で関わりのある団体の中からCAMPHOR-とKC3(関西情報系学生団体交流会)にご協力いただき、CAMPHOR-の上田蒼一朗さん、KC3の丸谷啓輔さんをお招きしてセッションを実施しました。

はじめにお二人から自己紹介とコミュニティ紹介をしていただきました。上田さんは京都大学大学院の学生で、2023年度の未踏スーパークリエータに選出されました。低レイヤーもインフラもWebも興味を持っているそうです。CAMPHOR-は2010年設立のコミュニティです。CAMPHOR- HOUSEという古民家を改装した拠点を持っていることが大きな特徴で、ここに学生が集まって技術談義をしたり、企業を招いてイベントを開催したりしています。さくらインターネットはCAMPHOR-が運用する各種サービスの基盤として「さくらのクラウド」を無償提供しています。

丸谷さんは近畿大学の学生で、KC3を運営しているNxTENDという団体で活動しています。KC3は関西圏の大学など各種学校に存在するIT系団体の集合体です。大きな行事は年に2回あり、1つはカンファレンス形式のKC3、もう1つはハッカソン形式で行われるKC3 Hackです。どちらも参加者は各団体に所属する学生に限られます。ちょうど2/9(日)〜24(月)にKC3Hack 2025が行われたところで、さくらインターネットも協賛しました。

その後、筆者から上図のようなお題を出してお二人に回答していただく形でディスカッションを行いました。

コミュニティに関わるきっかけ

はじめに問いかけた「コミュニティに関わるきっかけ」については、以下の回答がありました。

上田: セキュリティ・キャンプに参加したときに、一緒に参加していた人がCAMPHOR-の運営をやっていて、誘われてCAMPHOR- HOUSEに行くうちに居心地がよかったので定着しました。CAMPHOR-に参加したのは3回生からです。3回生ぐらいになると開発などもするようになりますが、周囲にその類の話ができる友達があまりおらず、それができる場がCAMPHOR-でした。

丸谷: 参加し始めたのは1回生の6月です(現在は2回生)。大学の先輩がNxTENDの運営メンバーで、誘われて参加しました。イベントはもともと好きで、しかも情報系の学生なので、IT関連のイベントがやれる場としてKC3は最適でした。

運営の楽しみとつらみ

次に「運営をやっていて楽しいことやつらいことは何ですか？」という質問をしてみました。これに対しては以下の回答がありました。

上田: CAMPHOR-に参加した人が、それをきっかけにステップアップしたり新たな挑戦を始めることに関われるのが楽しいです。イベントも好きで、CAMPHOR- HOUSEは定員20人の会場ぐらいなので密度の高いコミュニケーションができるのが良い点だと思います。

丸谷: イベントの懇親会で参加者の皆さんが楽しく交流している姿や、アンケートで「また参加したい」という回答をもらえるとうれしいです。企業とのつながりが持てることも良い点だと思います。つらいのは学業との両立ですね。大規模イベントでも7,8人程度のスタッフで運営しているので作業量が多いです。最近はイベントのリーダーも経験していますが、スタッフ全員のやる気を上げるのも苦労のひとつです。

KC3が主催するイベントの集合写真

関西と関東(など他地域)

続いて「関西と関東および他地域のコミュニティやイベントを見ていて、違いを感じることはありますか？」というお題を出してみました。これについてはお二人から次のような回答がありました。

丸谷: 関東は企業が開くイベントが多い印象があります。NxTENDは全国で4つほどコミュニティを運営していますが、関東は入る余地がなさそうです。関西は大学間のつながりが強いと思っています。

上田: 関西と関東というよりは、東京とそれ以外の地域で情報量の差を感じています。例えばセキュリティ・キャンプのような学生向けイベントも、関西にいるとそもそもそれを知る機会が少なく、知ったときにはもう年齢制限を超えていた、というような例も見かけます。

その他

最後に参加者との間で質疑応答をしました。地元の企業やコミュニティとのつながりはあるのか、学生に技術コミュニティに参加してもらうにはどうしたらよいか、技術コミュニティのイベント情報は学生に届いているのか、などの話題が出ました。

セッションを聞いていて、人のつながりでコミュニティに参加するのは昔も今も変わらないなと思ったのと(筆者も40年近く前に同様のルートで参加するようになって現在に至ります)、今ではITの分野でも多くの学生団体が存在し、それぞれ自分たちで考えて活動していることをとてもうれしく思いました。

10分でわかるJANOG55会場ネットワーク

JANOGセッションで発表中の金澤さん、遠北さん、栃澤さん、藤川さん (右から)

3番目のセッションもインフラ支援に関するものです。本イベントと同時期に京都のみやこめっせで開催されていたJANOG55ミーティングにおいて参加者向けの会場ネットワークを構築するにあたり、そのバックエンドとなるインフラ用に当社の「さくらのクラウド」を無償提供しました。そこでJANOG55のNOCチームから4名の方にお越しいただき、構築したネットワークの解説をしていただきました。発表者は、金澤直輝さん(JANOG55 NOCチーム)、栃澤侑人さん(東京都立産業技術高等専門学校)、藤川純さん(東京都立産業技術高等専門学校)、遠北涼さん(広島市立大学大学院)です。

JANOGのNOCはいくつかのチームに分かれていて、各チームごとの取り組みを紹介する形で発表が進行しました。その中から、さくらのクラウドを利用したサーバチームや監視チームの内容を中心にご紹介します。

上図が今回のサーバ構成と、さくらのクラウドのコントロールパネルで見るサーバ一覧です。一覧を見るとわかるように各機能とも2台ずつのサーバ構成になっています。検証から本番環境まで一貫してさくらのクラウドを利用したので、環境の移行を意識する必要がない点がとても楽だったとのことです。

さくらのクラウドと会場の間は、さくらのクラウド上に設置したVPCルータ上でVyOSを起動し、VPNを用いて接続しました。帯域はルータ＋スイッチを利用して1Gbpsを確保しました。

さくらのクラウドを使って提供した機能はDHCP、DNS、NTPといったところです。DHCPサーバはKeaを使用し、1日(さくらの夕べ当日はJANOGの1日目でした)だけで2646個のIPアドレスをリースしました。NTPサーバはchronyを使い、セイコーソリューションズから提供を受けたTS-2560を閉域モバイル網経由で接続して時刻情報を受信しました。

DNSもさくらのクラウドに作成したサーバ上で提供しました。権威サーバはCoreDNS、キャッシュサーバはPowerDNSで構築しました。KeepalivedやDNSDistを使って冗長化や負荷分散も行っています。

監視チームもさくらのクラウドを使って環境構築を行いました。上図が物理構成図で、2台のサーバに各種ソフトウェアをインストールして使用しました。さくらのクラウド側から監視するだけでなく、Zabbix Japanから提供を受けたZS-7700(上図中央下の白い機器)にて、会場のAPやスイッチの監視とともにさくらのクラウドの監視も行っていました。

監視の論理構成図を上に掲げます。非常に多くのソフトウェアを使っていることがわかります。監視を構成するコンポーネントが多いのは大変だが楽しいという感想を述べていました。

他チームの発表は誌面の関係で割愛しますが、WiFiのアクセスポイントを扱ったAPチーム、総延長4km以上のケーブルを配信したケーブルチーム、ASを持ちBGPによる対外接続を行ったバックボーンチーム、会場内ネットワークを担当したL2L3チームの発表がありました。NOCチームには学生も多く、学校では体験できない大規模ネットワークの構築を楽しんでいた様子がうかがえました。そして、NOCチームの尽力により4000人におよぶJANOG参加者が会場ネットワークを利用することができました。ありがとうございました。

おわりに

イベント終了後は会場近くの店に行って懇親会をしました。今回は学生コミュニティにご協力いただいたこともあって学生の参加が多く、JANOGに参加している遠征組もいれば地元の人もいて、新たな交流を生み出せてよかったと思います。

さくらの夕べは当社の拠点がない街で開催することも多く、集まってもらえるだろうかといつも不安になるのですが、今回も開催が近づくにつれて参加登録が大幅に増えて、当日は会場がほぼ満員になりました。たくさんのご参加ありがとうございました。次回がいつになるかはわかりませんが、また企画してみたいと思いますので、皆さんのご参加をお待ちしています。

それではまた次回のイベントでお会いしましょう！

たくさんの方にご参加いただきありがとうございました！
JANOGMackerelNOCコミュニティさくらのクラウドさくらの夕べ京都学生
法林浩之
大阪大学在学中に日本UNIXユーザ会に参加し、1992年より幹事(現会長)。職歴としてはソニー、インターネット総合研究所を経て、2008年に独立。現在はフリーランスエンジニアの活動と並行して、多彩なITイベントの企画・運営を行っている。特にトークセッションの司会に定評があり、これまでに1000人以上の講演者の相手を務めている。2015年からはさくらインターネットでの活動も展開し、さくらのナレッジの編集も担当。