課題解決事例 : 最先端のインターネットを構築する開発者との対談 | その1 Spread Group
Martin Breest が Senior Software Architect を務める Spread Group は、ドイツのライプツィヒを本拠地とする、オンデマンド印刷商品を提供する世界のオンライン販売ブランドを集めたサービスであり、Fastly のお客様でもあります。今回は Fastly の Principal Developer Advocate である Andrew Betts が、Fastly のコマンドの実行にチャットボットを使うというクリエイティブな発想や、失敗をすることの重要さ、そしてこの先取り組んでいきたい課題について Martin と対話しました。
Andrew : Fastly のサービスをクリエイティブに活用しているお客様は、プロダクトやその用途、お客様の Fastly の利用方法などについて、私たちの視野を広げてくれます。Spread Group では Fastly のプラットフォームを利用して非常に面白い試みを行なってきましたが、この度作ったチャットボットと、その使い道についてぜひ聞かせてください。
Martin : このチャットボットは今までで一番面白い作品だと思います。チャットボット自体はそこまで技術的に複雑なものではないんですが、使い道が結構斬新なんです。チャットボットを作ることで、いちいち運用チームに設定を頼まなくてはいけないブラックボックス的な存在であった CDN レイヤーが、誰でも容易に利用できるものになりました。
チャットボットのアイディアは、実は別の CDN ベンダーのプレゼンテーションを聞いている時に思いついたんですが、以前利用していた CDN での実行は難しかったので、ずっと放置していました。Fastly を導入してからは、必要な API や動的スニペットが使えるようになった上、変更も数秒でロールアウトできるので、やっとアイディアを実現することができました。
チャットボットの目標は、開発者に権限を与えることでした。CDN 機能を自らコントロールし、変更のロールアウトや好きなタイミングでのパージ、A/B テストの実行、IP のブロックなど、全てをチーム内のチャットのコンテキストで行えるようにしたかったのです。例えば、チャットで誰かが「今ペネトレーションテストが行われているようですが、どうしますか？」と呼びかけるとします。すると誰かが「そうですね、誰か対処をお願いします」と返信し、また別の人が「はい、今ブロックします」と答えるわけです。そうすることでチャットのコンテキスト内でペネトレーションテストをブロックすることができる上、チームメンバー全員にも知らせることができます。結構便利な機能ですよね。
チャットボットを利用できるようになって、チーム内のカルチャーや運用プロセスにおいて変わったことはありますか？
以前の CDN ベンダーでは、運用に関する変更が必要な場合、毎回チケットを起票しなければいけませんでした。つまり CDN レイヤーへの変更が適用されるまでに1日または数日待たなくてはいけませんでした。私が希望した設定がうまくロールアウトされることもあれば、そうでないこともありました。その繰り返しでした。
今ではとてもスムーズに変更を行うことができます。すべての CDN 設定が Git 内にあるので、使い慣れたツールを使って変更をロールアウトすることが可能です。例えば、よく設定変更を依頼してくる Spreadshirt チームから変更のリクエストを受けるとします。設定変更が完了したら、「変更をロールアウトしました。これが新しく改正された Git です。どうぞ確認してください」とチャットボットを通じて報告することができます。
また Teamshirts などのチームは、今では運用を自ら行なうようになりました。最初は私が代行してやっていましたが、あまりにも簡単なので自ら行うようになったんです。
開発者が望むレベルの権限を与えることで、すべてがよりスムーズに進むようになりました。設定変更、パージ、テストのロールアウトなどが実行されるまで何日も待つ必要がなくなりました。すべて即座に行うことができて、プロセスがとてもスムーズです。
またリリースにしたがう不安やストレスも軽減されるので、自信にもつながりますよね。
そうですね。またリアルタイムのログがありますから、トラブルが起こっても修正することができます。私たちは従業員を信用していますから、能力を発揮できるツールを与えたいのです。失敗したっていいんです。できれば同じ失敗はくり返したくはありませんが。
とても良い考え方だと思います。今ログの話がありましたが、Fastly のログ機能を結構使っていますよね。
そうなんです。以前の CDN ベンダーでは、ログは1時間遅れて配信されていました。それがまず1つ目の問題点でした。そしてもう1つの問題点は、カスタムデータでは40文字しか利用できなかったことです。本当の話ですよ。
Fastly を採用してからはリアルタイムでログを配信できるので、単純なものではリクエスト URL やステータスコード、複雑なものでは位置情報、デバイス情報、あらゆるヘッダーなど、なんでもログできるようになりました。また最近 proxy type と proxy description について知ったのですが、攻撃や詐欺のセキュリティリサーチで重宝しそうです。
つまりデータが手に入るので、さまざまな用途に活用できるということですね。ところで、ログ配信に ElasticSearch は使っていますか？
はい、ログを ElasticSearch のクラスターにストリームしているので、すぐにリサーチに使えて非常に便利です。アプリケーションログ、エラーログ、そしてそれぞれのチームが独自に書いたログなどがルーティングされるデータセンターに、Fastly からのログをつなげることで、リアルタイムでインサイトを取得することができます。
例えば、去年クレデンシャルスタッフィング攻撃が発生した際も、リアルタイムで状況を確認することができました。「今これが起こっているから、この特定のユーザーエージェント、または特定のユーザーエージェントとヘッダーのコンビネーションをブロックしよう」などと、すぐに対処することができました。また、ブロックの効果もリアルタイムで確認できるのが素晴らしいです。
また運用ログ以外にも、レポート用のログも利用しています。毎月 CDN にかかるコストやその理由を明確にする CDN レポートを公開することは、以前の CDN では不可能でした。このようなことを可能にしてくれるのが、Fastly と他のベンダーとの違いです。
多くの小売業者にとって、今はクリスマスシーズン真っ只中ですが、季節性についてお聞きしたいと思います。クリスマス期間が始まると、チームにどのような影響がありますか？またコロナ禍の現在、通常と違うことはありますか？
Spread Group はオンデマンド印刷ビジネスです。欧州と北米のさまざまな国にある製造施設で、従業員が実際に Tシャツなどの衣類や、マグカップ、グッズなどの商品にデザインを印刷しています。つまり私たちはデジタル企業でありながら、物理的な商品も扱う企業でもあるので、安全規制、ロックダウン、工場の閉鎖などの問題も関わってきます。今年の3月から4月にかけて工場の一部を閉鎖しなくてはいけなくなったのですが、ロックダウンと資金がいつまで続くか不明だったため、非常に不安定な状況でした。
幸いビジネスは回復しましたが、3月と4月の売り上げの低下を補ってくれたのがマスクの販売でした。日常的にマスクが必要になる中、好きなデザインを印刷したマスクを提供することができました。
そして Spreadshop のオンライン店舗の方の活気も戻りました。また私たちは Shopify のネット店舗に対してもオンデマンド印刷サービス SPOD (Spreadshirt Print-on-Demand) を提供しているので、そのサービスを通じて注文を受けることができました。最初はなかなか厳しかったですが、その後はおかげさまで好調でした。2020年は2桁増収を達成し、Spread Group にとってまたしても記録的な年になりそうです。
A/B テストも行っているそうですが、どのようなものを比較していますか。また、結果はどう測定していますか。実は Fastly を使った A/B テストのソリューションパターンは私がデザインしたものなので、Spread Group では私のソリューションを使っているのか、または別のものを使っているのか個人的に興味があります。
基本的にはあなたのソリューションを使っていますが、サービス設定に生成コードを含む動的スニペットを追加し、コマンドラインツールまたはチャットボットを使ってテストを開始・終了しています。
テストの対象はというと、比較的複雑なものです。つまり開発作業が必要なものですね。例えばマーケットプレイスの商品リストを比べる場合、デザインだけを表示するバージョン (デザインビュー) と、デザインが商品に合成されるバージョン (商品ビュー) を比較したりします。または、Tシャツのデザイン作成ツールのレイアウトを比較したりもします。最終的には Analytics チームが結果を分析し、A/B Test チームが仮説を検証し、結果を評価します。
Spread Group でこの先取り組んでいきたいと考えている、大きな技術的な課題はありますか。
Spread Group での悩みの種は画像配信です。時々、商品の画像を変えるんですが、それが結構厄介なんです。例えば最近マグカップの画像を変えたんですが、そうするとマグカップにデザインが合成されている画像を全て変えなくてはいけなくなる訳です。
つまりベースとなるマグカップの画像が変わってしまったため、マグカップに印刷可能なデザイン全てにおいてマグカップの画像を変えなくてはいけなくなったのですね。その場合、イメージオプティマイザーを利用してデザインを背景に合成していますか、それともオリジンで処理していますか？
とても良い質問ですね。イメージオプティマイザーを利用することで3つのメリットがあります。1つ目は、JPEG や WEBP などさまざまな形式で画像を配信できるようになること。そして2つ目は、378ピクセル、500ピクセル、800ピクセルなど、画像を簡単にリサイズし配信できることです。そして3つ目がオーバーレイですが、これは少し複雑です。
人が実際に商品を着ている 3D モデル画像を導入する前は、無地の Tシャツにデザインを合成するだけだったので、2D 画像変換やオーバーレイを使って比較的簡単に行うことができました。
ですが 3D の場合、Tシャツにそのまま合成できる訳ではないので、そう簡単にはいきません。3D モデル画像だと、人物が傾いていたりする場合、デザインもその角度に合わせて合成しなくてはいけません。例えばシャツの袖にデザインが印刷されている場合は、正面から見ると袖のデザインは一部しか見えないですよね。このように、比較的複雑なのです。バックエンドでは Spread Group 独自の Java で記述された 3D レンダリングプロセスを利用していますが、このプロセスをよりスケーラブルかつ簡単に行うために、エッジへ移行する方法を考えています。
今思いついたのですが、ソース画像にゆがみメッシュがあれば、エッジで背景のゆがみメッシュに合わせた画像の行列変換が理論的には可能だと思います。VCL や現在のイメージオプティマイザーではできませんが、Compute@Edge なら可能です。
それは良いですね。ぜひ試してみたいと思います。
