Let's Encryptは、Web PKIエコシステムの健全性を維持するというコミットメントの一環として、2019年からCertificate Transparency（CT）ログを運用しています。CTログは、暗号化されたWebの重要なインフラストラクチャとなっていますが¹、高いレベルの信頼性で運用するのが難しいという評判があります。「適格」と見なされているログを運用している組織は6つだけです。²

当社のオークログは、完全にオープンソースのスタックで実行されている唯一の適格なCTログです³。CTエコシステムへの参加障壁を他の組織にとって低くするために、MariaDBによってサポートされているGoogleのTrillianに基づいてログを起動することを計画している人にとって役立つ可能性のある、オークに対する最近の変更点をいくつか紹介します。

• MariaDB上のTrillianのディスクI/Oワークロードは、フロントエンドのレート制限によって簡単に軽減でき、

• 新しい年次CTログをそれぞれ独自のTrillian/MariaDBスタックに分割することには、複雑さに見合うだけの価値があります。

この記事では、以前の記事Let's EncryptによるCTログの運用方法の情報の一部を更新します。

オープンソースを維持しながらオークを成長させる

オークは、無料のオープンソーススタックで実行されます。GoogleのTrillianデータストアは、MariaDBによってサポートされ、Amazonのリレーショナルデータベースサービス（RDS）を介してAmazon Web Services（AWS）で実行されます。私たちの知る限り、オークはクローズドソースコンポーネントのない唯一の信頼できるCTログです³。

Trillianの他のオペレーターは、データを異なる方法でセグメント化する異なるデータベースを選択しましたが、提供されているMySQL互換データストアは、Let's EncryptのCTログの量（現在、月400 GBを超える）に対応できています。MariaDB上のオークのスケーリングのストーリーは、リレーショナルデータベースの典型的なものですが、パフォーマンス要件は厳格です。

オークの資格を維持する

Certificate Transparencyログオペレーターが従うポリシーでは、ログ自体に誤りがないという、より絶対的で困難な要件に加えて、重大なダウンタイムがないことが求められます。Certificate Transparencyの追加専用性により、一見軽微なデータの破損がログの永久的な失格につながります⁴。破損の影響を最小限に抑えるため、またスケーラビリティの理由から、CTログは、含まれる証明書をシャードと呼ばれる異なる小さな個々のCTログに配布するのが一般的になっています。

長年のデータを多くのツリーに分割する

Let's EncryptオークCTログは、実際には、それぞれが期間の名前が付けられた多くの個々のCTログシャードで構成されています。オーク2020には2020年に期限切れになった証明書が含まれ、オーク2022には2022年に期限切れになる証明書が含まれます。簡単に参照できるように、これらを「一時ログシャード」と呼びますが、実際にはそれぞれがオークファミリー名を共有する個々のCTログです。

単一のTrillianインストールを構成して、複数のCTログシャードをサポートするのは簡単です。各ログシャードはバッキングデータベース内にストレージが割り当てられ、Trillianログサーバーは、構成されているすべてのログのリクエストを処理できます。

Trillianデータベーススキーマは非常にコンパクトで理解しやすいです

• 構成された各ログにはツリーIDが割り当てられ、メタデータはいくつかのテーブルにあります。

• すべてのログエントリ（この場合は証明書）は、LeafDataに行を取得します。

• シーケンスされていないエントリは、Unsequencedテーブルに行を取得します。このテーブルは通常、Trillianログ署名サービスによって空のままにされます。

• シーケンスされると、エントリはUnsequencedテーブルから削除され、SequencedLeafDataに行として追加されます。

簡単に言うと、Trillianの特定のコピーに対していくつの異なる証明書トランスペアレンシーツリーとサブツリーを設定しても、それらのすべてがデータの大部分を、特にDERでエンコードされた証明書自体を、1つのLeafDataテーブルに織り交ぜて格納します。 Trillianログサーバーは単一のMySQL接続URIでのみ構成できるため、単一のデータベースに制限されているため、その単一のテーブルは非常に大きくなる可能性があります。

オークの場合、データベースは現在、月約400 GBの速度で増加しています。TLSの使用が増加し、より多くの認証局がログに証明書を送信するにつれて、その速度は常に増加しています。

Amazon RDSのサイズ制限

2021年3月、Amazon RDSには、RDSがテーブルごとに1つのファイルを使用するように構成されている場合、テーブルスペースごとに16TBの制限があることがわかりました。すべてのCTログシャードに対して行っていたように。幸いなことに、テスト環境のTestflumeログで最初にこの制限に達しました。

Testflumeの目的の一部は、本番ログの合計サイズよりも先に成長し、本番オークログよりも積極的な構成オプションで成長をテストすることであり、これらの点で非常に成功しました。

データベース設計の再検討

ブログ記事Let's EncryptによるCTログの運用方法では、毎年「前年のシャードをフリーズし、それほど高価ではないサービスインフラストラクチャに移動して、ストレージをライブシャードに再利用する予定」と書きました。ただし、同じデータベースインスタンスからトラフィックを提供し続ける場合は、これは実用的ではありません。使用中のInnoDBテーブルからテラバイトの行を削除することはできません。 TrillianのMySQL互換ストレージバックエンドも同意します。実装されているTrillianの組み込みツリー削除メカニズムは、ツリーを「ソフト削除」としてマークし、LeafDataテーブル（およびその他）からのデータの削除を管理者の課題として残します。

TrillianのMySQL互換バックエンドは、LeafDataを複数のテーブルに分割することを単独ではサポートしておらず、これらのテーブルから古いデータを削除するとデータベースサーバー全体のパフォーマンスが低下するため、オークCTログのスケールを継続するには、代わりに前のシーズンのデータを別の方法で削除する必要があります。

ログシャードごとに個別のスキーマを持つ単一のRDSインスタンス

既存のMariaDBがサポートするAmazon RDSインスタンスに新しいデータベーススキーマを追加することを検討しました。この設計では、一時ログシャードごとにTrillian CTフロントエンド（CTFE）インスタンスを実行します。それぞれが個々のTrillianログサーバーおよびログ署名インスタンスを指し、それら自体が特定の時間的に識別されたデータベーススキーマ名とテーブルスペースを指します。これは費用対効果が高く、16 TBの制限を回避するための十分な余裕が得られます。

ただし、基盤となるデータベースの一部で重いメンテナンスが必要な場合は、含まれるすべてのログシャードに影響します。特に、Let's Encrypt CAインフラストラクチャ内でInnoDBでMariaDBを使用していることから、数テラバイトのテーブルを切り捨てて削除すると、操作の実行中にデータベース全体のパフォーマンスの問題が発生することがわかっています。CAインフラストラクチャ内では、データベースレプリカでのみテーブルデータを削除することで、このパフォーマンスの問題を軽減しています。これは、RDSのようなよりハンズオフのマネージドホスティング環境ではより複雑です。

データ衛生の問題として古いデータを定期的に消去したいと考えており、CTログのパフォーマンス要件は厳しいため、このオプションは実行可能ではありませんでした。

ログシャードごとの個別のRDSインスタンス

管理対象システムコンポーネントの数は増加しますが、各一時ログシャードに独自のデータベースインスタンスを与える方がはるかにクリーンです。ログシャードごとの個別のスキーママネージドホスティング環境ではより複雑です。デルと同様に、現在、各一時ログシャードに対してTrillian CTFE、ログサーバー、およびログ署名インスタンスを実行しています。ただし、各ログシャードは、ログのアクティブな存続期間中は独自のRDSインスタンスを取得します⁵。ログのシャットダウン時に、RDSインスタンスは単にプロビジョニング解除されます。

オークログの元の仕様では、これには大量のデータI/Oリソースを割り当てる必要があります。ただし、Testflumeログを実行した長年の経験から、AWSのTrillianには可能な限り最高のディスクパフォーマンスは必要ないことがわかりました。

IOPSの調整

当時利用可能な最高のパフォーマンスのAWS Elastic Block Storageを使用してオークを立ち上げました。プロビジョンドIOPS SSD（タイプio1）。CTログの厳格なパフォーマンス要件のため、ディスクI/Oの最高のパフォーマンスがなければ、失格につながる可能性のあるレイテンシの問題が発生するのではないかと心配していました。ブログ記事Let's EncryptによるCTログの運用方法で述べたように、将来的にはよりシンプルなストレージタイプを使用できることを期待していました。

それをテストするために、テストCTログTestflumeに汎用SSDストレージタイプ（タイプgp2）を使用し、ログの存続期間にわたって名目上の結果を得ました。実際には、Trillianがデータベースインデックスをうまく利用しているため、より高いパフォーマンスは不要でした。最初のリーフエントリからログツリー全体をダウンロードすることは、ディスクI/Oの最も重要な需要であり、その操作方法は、ロードバランサー層のレート制限によって簡単に管理できます。

2022年と2023年のオークシャードは、現在タイプgp2ストレージを使用しており、良好に機能しています。

相乗的に、各一時ログシャードに対して個別のRDSインスタンスを実行するという以前の変更により、TrillianのI/O負荷がさらに軽減されました。トリミングされたデータのより大きな割合が、MariaDBのインメモリバッファプールに収まります。

今後の改善

CTログの増加率は今後も加速し続けることは明らかです。最終的に、このアーキテクチャにとどまると、1年間のCTログでも16 TBのテーブルサイズ制限を超えてしまいます。それに先立って、さらにアクションを起こす必要があります。それらのいくつかは次のとおりです。

• 一時ログシャーディング戦略を、おそらく3か月または6か月ごとに、1年未満の間隔に変更します。

• 中間証明書を重複排除することにより、TrillianのMySQL互換ストレージバックエンドの絶対ストレージ要件を削減します。

• TrillianのMySQL互換ストレージバックエンドにテーブルシャーディングを追加するためのパッチを提供します。

• ストレージバックエンド全体を、おそらくシャーディング対応のミドルウェア、または別のより水平方向にスケーラブルなオープンソースシステムに変更します。

また、現在のTestflume CTログを根絶し、Saplingという名前の代替品をオンラインにしました。以前と同様に、このテスト専用のログは、将来的に成果を上げる可能性のある、より積極的な構成を評価します。

いつものように、データのスケーリングは難しい部分です

CTログのパフォーマンス要件は厳格ですが、スケーラビリティの難しさの大部分は、大量のデータと、高くて常に増加する成長率に関係しています。これはリレーショナルデータベースの方法です。水平方向のスケーリングは引き続きソリューションであり、オープンソースのTrillianおよびMariaDBスタックに簡単に適用できます。

Let's Encryptのサポート

非営利プロジェクトとして、私たちの資金は100%、ユーザーとサポーターのコミュニティからの寄付によって賄われています。私たちは、公共の利益のためにサービスを提供するために、彼らの支援に依存しています。あなたの会社や組織がLet's Encryptをスポンサーしたい場合は、sponsor@letsencrypt.orgまでメールでご連絡ください。もし寄付によって私たちを支援できる場合は、個人からの寄付をお願いします。