オートスケールにおけるオブザーバビリティへの取り組みspeakerdeck.com山本:私の発表では「オートスケールにおけるオブザーバビリティへの取り組み」というタイトルでお話ししたいと思います。普段は、「さくらのクラウド」と呼ばれる、パブリッククラウドを作る業務を行っています。この「さくらのクラウド」はガバメントクラウドに条件付き認定されているクラウドです。さくらのクラウドは現在ガバメントクラウドが要求する技術要件を満たしていないため、不足している要件を2025年度末までにすべて満たすという条件付きで認定されている状態です。今はそれら機能を実装することを進めているフェーズです。本日は、パブリッククラウドの機能を実装していく中で、以下についてお話ししたいと思います。発表内容オートスケールの紹介オブザーバビリティの取り組み採用したツールの使い勝手オートスケールオートスケールはクラウドサーバーなどが備えている機能で、あらかじめ設定したサーバーの負荷状況に応じ、自動的にサーバー台数や性能を増減させるサービスです。弊社のオートスケールの特徴としては、サーバーのスペックやルーターの帯域幅を動的に増減させる、いわゆる「垂直スケール」と呼ばれるような機能を提供していることです。サーバーの台数を増減させる「水平スケール」だけではなく、サーバーのスペックやルーターの帯域幅を動的に増減させる、いわゆる「垂直スケール」と呼ばれるような機能も提供していることです。https://manual.sakura.ad.jp/cloud/autoscale/autoscale.htmlオートスケールのバックエンド構成このオートスケールについて、下図のような構成になっています。インフラ自体をさくらのクラウド上に配置しており、この上にサーバやデータベースを配置しています。サーバについては、2台1つをペアとしており、この2台で冗長構成を組んでいます。そのうちの1つをAPIサーバとして稼働させているような状態です。サーバは、コントロールプレーンとデータプレーンに分かれており、下図で「autoscale-manager」とあるのがコントロールプレーンとして動いています。お客様がオートスケールを作りますと、このコントローラーのところにリクエストが来て、実際にオートスケールとして動かすために必要な各種コンポーネントをデプロイする流れになっています。データプレーンについては、弊社はsystemdをデータプレーンとして採用しています。1つのリソースに対して、例えばCPUの負荷を測るようなものであったり、トラフィックの量を測るようなものなど、いくつものコンポーネントを組み合わせて動くものになっています。1台のサーバ上で起動できるプロセスには上限があるので、そのような場合、横向きにペアを増やしていって、スケールアウトさせる構成になっています。導入ここまでがオートスケールの基本的な構成についてでしたが、このように複数のコンポーネントが分散して動くと日々の運用で大変なことがあります。可観測生(オブザーバビリティ)を高めたいという課題をあり、それを解決するためにOpenTelemetryの導入を進めていきました。対応するにあたり、先ほどの下図の構成を大幅に変えて導入するのではなく、アドオンする形で導入しました。対応)OpenTelemetryをアドオンした後が下図になります。SigNozについてSigNozについてあまり馴染みがない方もいるかと思いますが、これは、オープンソースで公開されているオープンテレメトリーディストリビューションの1つです。・できるだけ外部サービスを使いたくなかった→セルフホストできる&いざとなればソースコードを追える・運用ノウハウがあるものを選びたかった→ClickHouseなら運用ノウハウを持っていた実際にSigNozを選んでどうだったか・デプロイ〜運用は非常に楽になりました→手軽に始められてgood・ダッシュボードは問題なく使える→ただしある程度自分で作り込む必要あり(公開ダッシュボードが少ない)・トレースのUIについては不満あり→痒いところに手が届かない感じまとめまとめとして以下の事例を紹介させていただきます。オートスケールでOpenTelemetryを導入OTelディストリビューションとしてSigNozを利用中SigNozの使い勝手は悪くない最後にさくらインターネットではエンジニア採用を強化していますので、ご興味ある方は、ぜひご応募ください。