TLS終端サーバーのロードバランシングについて

すいません。完全に知識不足でDNS ラウンドロビン以外で、冗長化できないとおもっていました。普通にL4ロードバランサで冗長化できましたね。はい。

説明する前にロードバランサについておさらい

詳しい説明がここに載っている。
- L7ロードバランサとL4ロードバランサ - Qiita
  - パケットの流れとかよくわからん人にとってはわからんところだと思うけど、流れは概ね理解できると思います。

解決策

DNSにはL4ロードバランサのIPを指定する。
L4ロードバランサからTLS終端サーバー群へロードバランシングしてくれる。

はい、これだけですね。よくよく考えれば当たり前のことだと思いました。

もちろん当たり前なのですが、SSL証明書をTLS終端サーバー群に対してインストールしておくことが必須になります。

完全に勘違いしていたこと

DNSに設定するのはTLS終端サーバーのものを直接指定しなければ行けないと思いこんでた。
- L7がTCP終端しているのをそもそも理解していなかったことと、L4がTCP終端しないでそのままパケットを流すことを理解していなかった。
  - DNSで設定したロードバランサ上でもうSSL証明書を解決できないと行けないものだとばかり思っていた。
  - L4がそのまま処理を流すのであればDNSが知っているべき宛先としてはL4のロードバランサで問題ない。
  - TLS終端を実際に行う部分でSSL証明書を解決できれば実はOKなのだ。（ここでTCP終端しているわけだから。）

冗長化したTLS終端サーバーの証明書関連の課題

とにかく難しいと思っている。（ここから本題感ある。）
- というか難しいからハードへのリスク承知でSPOFにした記憶
  - そしたら運良く（悪く？）障害を引いた…
  - そもそもクラウドの場合、冗長化しないとSLA保証されない場合があるしねぇ…
TLS終端サーバーがすべてのアクセスの起点になっているので、TLS終端サーバーで粗相があるとすべてのアクセスに対して問題が発生してしまうから難しい。

証明書の読み込み

冗長化するし、設定したSSL証明書をどうやってサーバー間で共有するかも課題。アプリケーションサーバーなんかよりも考えることも多くて大変。

これはいくつか対応策はあるけど、できればインフラ専任エンジニアがいないので、なるべく普遍的な技術スタックでやりたい。。。

シンプルに証明書部分だけをNFSでマウント

必ずこの部分がボトルネックになるので却下。
そもそも弊社でSPOFだったTLS終端サーバーに対して、冗長化を少し考え始めたのは、ディスク（インスタンスに対してという意味）破損があったからなので…

ngx_mrubyで証明書を動的読み込み

動的に読み込めばOKというもの。
証明書自体は普段はMySQLに置いておいて、証明書をRedisにキャッシュしてやるなどすればいいと思う。
これについてはペパボやはてなが事例公開しているので、同様なことで悩んでいる場合は目を通しておくといいかもしれない。
- 動的証明書読み込み ngx_mruby編 #hoscon / GMO HosCon 2016 - Speaker Deck
- ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ / The construction of large scale TLS certificates management system with AWS - Speaker Deck
ただまぁ、例えばキャッシュをRedisに、マスターデータをMySQLに格納するとなった場合、mrubyからちゃんとデータ取得時に「タイムアウト」だったり「コネクションエラー」をWebアプリケーション以上に適切にハンドリングを行なったり、X秒経過で強制タイムアウトにするかみたいな設定はシビアにしないと行けないと思っています。
- すべての必ずアクセスを前段で受けるので、ここでのスループットが全体のスループットに影響するので、パフォーマンスについてははじめからちゃんとしておくといいと思った。

TLS終端サーバーを自前運用しない

AWSだとALB、AzureだとApplication Gateway使えってやつですね。
本当に特別な事情がない限りこれが安心安全。
- AWSとかAzure自体が駄目だったら、言い方は悪いけど、クラウドベンダーのせいにできる。
- それで怒られるような規模なら専任にインフラエンジニアいるでしょ。
ただし弊社案件では、独自ドメインの証明書を使いたいのと、設定する証明書に上限は設けられないので使えない。
- 使えるなら絶対に使っている。
- ALBやApplication Gatewayは1つにつき証明書が20〜25だったと思う。
  - 足らんわっ・・・まるで・・・

Let’s Encryptでの証明書の取得・更新について

弊社では独自ドメインの証明書をLet’s Encryptを使って取得しているのでそっちの都合で「証明書の取得や更新」について色々考えてみました。

これもさっきのはてなとペパボの記事でLet’s Encryptでの証明書を取得する事例について紹介されているので、それを見て自分でどう思ったかを簡単にまとめておく。

speakerdeck.com
speakerdeck.com
tech.pepabo.com
独自ドメインのSSL証明書をLet’s Encryptでやる場合、TLS終端サーバーとは疎結合な仕組みにしておくと幸せになれると思った。
- 例えば、TLS終端サーバー「にだけ」SSL証明書を保存しないようにする。
  - RDBにも保存しておくといいし、念のためにS3にも入れておきましょうなど。
    - しかしこれを実現するためには「SSL証明書取得システム」が必要になる。というかないと厳しい。
    - 「SSL証明書取得システム」はお手軽にシュッと作れるものではないと思ってて、実装コストもまぁまぁ高いと思う。
    - 弊社用途だと、レンタルサーバー屋さんでも大手ブログサービスでもないのでそこまで爆発的に増えることはしばらくないと思うんだけども…
- TLS終端サーバーの責務は「証明書を名前解決して後続に処理をルーティングさせる」ことだけに集中させるべき。
  - 責務が多いと、ngx_mrubyの処理が多くなって来るし、証明書を取得するのは初回だけ、更新も3ヶ月に1回なので。
  - 更にいうと、サイトによってはEV証明書使いたいので、Let’sEncryptを使いたくないケースも想定されるので、あんまりべったりしているとあとから大変になる。
  - 更新方法を素朴に「TLS終端サーバーでCronを回す」のはお手軽だけど更新漏れに気づけない場合があるし、気づくための実装がとにかく大変。
    - なので上記のようにサービス分割しておくと、実装も楽になるともう。

まとめ

TLS終端サーバーの冗長化、とにかく大変そう…😇
弱小スタートアップがサクッと作れるようなスタックがほしい。。。

【WIP】TLS終端サーバーを冗長化するために考えること

2019-04-08 08:00:47 +0900