BIG-IP Forward Proxy構成で得た教訓

筆者がBIG-IP Forward Proxy構成の導入において経験した内容を元に、BIG-IP全般に通ずる点をまとめました。
BIG-IP Forward Proxy構成のスライド資料と合わせてご覧ください。

構成とモジュールの観点

結論先出ですが、BIG-IPでは「どのような構成であるか？」が重要な要素となってきます。
今のは何も聞かなかったものとして順を追って説明していきます。

まず初めに、BIG-IPにはいくつかのモジュールがあります。具体的な例を挙げると、LB構成で有名なLTM (Local Traffic Manager)や、SSL-VPN構成で有名なAPM (Access Policy Manager)です。

では、BIG-IPの案件の話が持ち上がった場合に、どのような点を気にされるでしょうか？
先の話が印象に残っていれば、「どのモジュールを使うか？」に焦点が当たるかもしれません。

次にモジュールの話に焦点を当てて、APMのモジュールを使用する場合は、どのような構成の案件になるでしょうか？
それはSSL-VPN構成かも知れませんし、SSO (Single Sign On)構成かも知れません。もしくは思いもしなかった構成かも知れません。よって、一意に断定できません。

そのため、BIG-IPを取り扱う際は、「どのような構成であるか？」が重要な要素となってきます。そして、構成が分かれば、お客様の要件を満たすようにモジュールやアドオンを組み合わせていくのが妥当性のある流れだと筆者は考えています。

では、Forward Proxy構成を例にとって説明します。
Forward Proxy構成として単に動作させるだけであれば、LTMのみでも設定可能です。ですが、現代ではセキュリティが重要視される流れがあるため、一般的にはアクセス制御が必要となり、APMを組み合わせる必要が出てくるでしょう。さらに、URLフィルタリングの動的データベースを使いたければ、SWG (Secure Web Gateway)のアドオンも必要になります。また、Forward Proxy構成をセットアップウィザードのように設定可能にするSSLO (SSL Orchestrator)と呼ばれるモジュールもあります。

このように一つの構成でもモジュールやアドオンの組み合わせは様々になります。

よって、「BIG-IP APM案件の過去実績があります。」のような明確性のない宣伝文句は、認識齟齬を生む可能性があります。

また、構成の話であっても「BIG-IP案件でのProxyの実績があります。」のような宣伝文句は、Forward ProxyかReverse Proxyで解釈が変わってきてしまいます。

煽るような書き方をしましたが、ネタではなく重要な要素であるため強調しております。

コード拡張の観点

BIG-IPはiRulesによる柔軟なコード拡張が可能です。しかし、言い方を変えれば、柔軟すぎるコード拡張により、スパゲッティコードを生み出す可能性を秘めています。

筆者が特に危険だと考えているのが、一からの機能(Function)の開発です。

例えば、更改案件では、既存で利用している機能を更改後も引き続き利用したい場合が多々あります。その場合、BIG-IPの標準的な機能で実現できないものは、iRulesでの実装が考えられます。

一般的に、製品が持つ機能はメーカーが品質の担保をしています。そして、ファームウェアのアップデートに伴う、機能追加の恩恵を受けられる可能性があります。時代の流れ共に技術革新が起こりニーズは変化していくため、構成によっては機能追加が重要な要素となってきます。特にInternetは不特定多数の集合体であるため、相手側のサービス仕様の変化に合わせて追従が必要な場合が考えられます。

それを一から機能の開発となると、開発者自らが品質を担保し、状況に応じて機能の追加対応などが必要なってきます。また、コード拡張によって脆弱性を新たに作りこまないためにセキュリティも重要視されます。
そして、BIG-IP自体とアプリケーション開発への有識者が必要となるため、必要となるスキルセットも高くなる点も考慮事項に入ります。

特記しますが、iRulesは、Sorryサーバに振り分けるような意図(Intent)を動作として反映させるには理に適っていると筆者は考えているため、iRulesによるコード拡張を完全に否定したいわけではありません。

PoC (Proof of Concept)の観点

製品選定におけるPoCにおいてには、お客様要件の実現性が重要な要素となってきます。そこで、iRulesで要件に応じた機能を作りこみ、お客様要件を無理やり実現する方法があります。

恣意的であろうとなかろうとも、コード拡張による実現が可能であればエンジニアとしては示さざるを得ないので、エンドユーザー側の自己防衛としても意識が必要な点となります。

そのため、PoCにおいては、iRulesによる実現の仕方の妥当性の考慮が必要となります。また、機能単体では実現可能であっても、それらを組み合わせて条件に応じて機能を使い分ける場合は、実現性が難しくなる場合があります。 PoCの段階では具体的な要件として固まっていない場合もあるので、本番導入になってから特に問題となりやすい点です。