通常の日にLet's Encryptは、ほぼ200万件の証明書を発行しています。しかし、インターネットにとって不可欠なインフラストラクチャがどのような準備を必要とするかについて考えるとき、私たちは通常の日々について考えているわけではありません。私たちは起こりうる最も困難な状況に最善を尽くして対応できるように準備したいと考えています。最悪のシナリオでは、広範な混乱を避けるために、24時間以内にすべての証明書を再発行したいと考えるかもしれません。つまり、1日に2億件の証明書を発行する準備を整える必要があります。これは、公的に信頼されているCAがこれまでに行ったことがないことです。

私たちは最近、1日に2億件の証明書を発行するために必要な作業と投資のほとんどを完了しました。その内容を皆様にお知らせしたいと思います。このすべては、スポンサーと資金提供者、およびCisco、Thales、およびFortinetからの主要なハードウェアの貢献によって可能になりました。

シナリオ

セキュリティとコンプライアンスのイベントは、私たちの業界では確実です。明らかに、それらを最小限に抑えようと努めていますが、それらが発生すると予想されるため、可能な限り最善の方法で対応できるように準備に多くの時間を費やしています。

2020年2月には、コンプライアンスに影響を与えるバグにより、300万件のアクティブな証明書を失効させて置き換える必要がありました。これは、すべてのアクティブな証明書の約2.6％でした。

もしそのバグがすべての証明書に影響を与えていたらどうなっていたでしょうか？それは2億4千万以上のドメインをカバーする1億5千万以上の証明書です。さらに深刻なバグで、24時間以内にすべての証明書を失効させて置き換える必要があった場合はどうでしょう？それは、私たちが準備する必要がある最悪のシナリオです。

さらに悪いことに、インシデント中は問題の評価と意思決定に時間がかかるため、24時間タイマーの開始からしばらく経って失効と再発行を開始することになります。つまり、1億5千万以上の証明書を失効させて置き換えるという重大な決定が下された後、実際には時間が短くなります。

インフラストラクチャの改善

システムを確認したところ、1日に2億件の証明書を置き換えることを妨げる4つの主要なボトルネックがあることがわかりました。データベースのパフォーマンス、内部ネットワーク速度、暗号化署名モジュール（HSM）のパフォーマンス、および帯域幅です。

データベースのパフォーマンス

Let's Encryptは、私たちが提供するサービスの中心に主要な認証局データベースを持っています。これは、証明書の発行状況と関連するアカウントを追跡します。読み取りも多いですが、書き込みが多いです。常に、単一のデータベースサーバーがライターであり、レプリカを持つ同一のマシンに一部の読み取りが向けられます。シングルライターの非クラスター化戦略は、一貫性に役立ち、複雑さを軽減しますが、書き込みと一部の読み取りが単一のマシンのパフォーマンス制約内で動作する必要があることを意味します。

以前の世代のデータベースサーバーには、合計24個の物理コアを備えたデュアルIntel Xeon E5-2650 v4 CPUがありました。これらは、RAID 10構成でSATA経由で接続された24個の3.8TB SSDを備えた1TBのメモリを持っていました。これらは日常的な発行には問題ありませんでしたが、1日ですべての証明書を置き換えることはできませんでした。

私たちはそれらを、合計64個の物理コアを備えたデュアルAMD EPYC 7542 CPUを搭載したDellの新世代のデータベースサーバーに置き換えました。これらのマシンは、2TBのより高速なRAMを備えています。より高速なCPUと2倍のメモリは優れていますが、これらのマシンについて本当に興味深いのは、EPYC CPUがそれぞれ128レーンのPCIe4を提供することです。これは、大量のI/Oパフォーマンスのために24個の6.4TB NVMEドライブを搭載できることを意味します。NVMEには実行可能なハードウェアRAIDがないため、必要なデータ保護を提供するためにZFSに切り替えました。

内部ネットワーク

Let's Encryptのインフラストラクチャは、もともと1G銅線ネットワークで構築されていました。2Gパフォーマンスのための複数の接続のボンディングと、スイッチで利用可能な非常に限られた数の10Gポートの使用の間で、2020年まで非常にうまく機能しました。

2020年までに、内部で移動していたデータの量が多すぎて、1G銅線では効率的に処理できなくなりました。一部の通常の操作は、私たちが望むよりも大幅に遅く（例：バックアップ、レプリカ）、インシデント中は1Gネットワークが応答に大幅な遅延を引き起こす可能性がありました。

私たちは当初10Gへのアップグレードを検討しましたが、25Gファイバーへのアップグレードはそれほど高価ではないことを知りました。Ciscoは最終的にこのアップグレードに必要なスイッチと機器のほとんどを寛大に寄付し、多くのサーバーNICを交換した後、Let's Encryptは現在25Gファイバーネットワークで稼働しています！

面白い話があります。2014年に、Ciscoは元のLet's Encryptインフラストラクチャの構築に使用するために非常に優れた10Gファイバースイッチを寄贈しました。当時の私たちのキャビネットは奥行きが異常に短かったため、10Gスイッチは物理的に収まりませんでした。物理的に小さい1Gスイッチのためにそれらを返品する必要がありました。当時は1Gで十分であるように見えました。その後、標準の奥行きを備えた新しいキャビネットに移動しました！

HSMのパフォーマンス

各Let's Encryptデータセンターには、すべての証明書とそのOCSP応答に署名するLuna HSMのペアがあります。2億件の証明書を失効させて再発行したい場合は、Luna HSMが次の暗号化署名操作を実行する必要があります。

  • 失効のための2億件のOCSP応答署名
  • 代替証明書のための2億件の証明書署名
  • 新しい証明書のための2億件のOCSP応答署名

つまり、リクエストクラスタリングを考慮したパフォーマンスオーバーヘッドを含めて、24時間以内に6億件の暗号化署名を実行する必要があります。

インシデント中は1つのデータセンターしかオンラインにならない可能性があると想定する必要があるため、HSMのパフォーマンスについて考えるときは、1つのペアで何ができるかを考えています。以前のHSMは、1秒あたり約1,100回の署名操作を実行でき、ペア間で2,200回実行できました。これは、フルキャパシティで動作すると、24時間で190,080,000件の署名になります。これでは不十分です。

必要な場所に到達するために、Thalesは、約10倍のパフォーマンス（1秒あたり約10,000回の署名操作、ペア間で20,000回）を備えた新しいHSMを寛大に寄付しました。これは、単一のデータセンターから24時間で864,000,000回の署名操作を実行できることを意味します。

帯域幅

証明書の発行は特に帯域幅を消費しませんが、インシデント中は通常、システム回復と分析のために多くの帯域幅を使用します。分析とフォレンジックの目的で、データセンターとクラウド間で大量のログやその他のファイルを移動します。大規模なデータベースを同期する必要がある場合があります。コピーと追加のバックアップを作成します。データセンターの接続が遅いと、応答が遅くなります。

データセンターの接続速度が応答時間を大幅に増加させる可能性があると判断した後、それに応じて帯域幅を増やしました。Fortinetは、これらのより大容量の接続を保護および管理するのに役立つハードウェアを提供しました。

API拡張

これらのすべての証明書を置き換えるには、ACMEクライアントに早期更新を実行するように通知するための効率的で自動化された方法が必要です。通常、ACMEクライアントは、有効期間の3分の1が残っているときに証明書を更新し、それ以外の場合はサーバーに連絡しません。私たちは昨年、クライアントがACMEサーバーに定期的にポーリングして早期更新イベントを検出する方法を説明するACMEのドラフト拡張を公開しました。私たちはそのドラフトを洗練し、実装し、クライアントと大規模なインテグレーターと協力してクライアント側で実装する予定です。

Let's Encryptのサポート

私たちは、サービスを提供するために、ユーザーとサポーターのコミュニティからの貢献に依存しています。あなたの会社または組織がLet's Encryptのスポンサーになりたい場合は、sponsor@letsencrypt.orgまでメールでお問い合わせください。可能であれば、個別の貢献をお願いします。