microXchg Conference 2016で，Zalandoは，同社がAmazon Web Service(AWS)を利用する複数の自律型チームを対象に開発した，監査準拠のPlatform as a Service(PaaS)の開発経緯について発表した。InfoQは先日，同社クラウドアーキテクトのTobias Sarnowski氏と席を共にする機会を得たので，同プラットフォームに関する詳細を聞くことにした。
開発から学んだ主な教訓としては，1) 自律型チームの必要性，2) 技術組織の成長に伴う開発のスケールアップには技術的プラットフォーム(PaaS)のサポートが不可欠であること，3) PaaS上での行為に対する監査が法律と運用診断の両面から必須であること，4) 技術的なビジョン(とそれに対応する”ゲームのルール”)を企業内の全員が共有し理解することが，一貫性のある意思決定を行なう上で重要であること，などが挙げられる。
InfoQ: Tobiasさん，こんにちは！今日はInfoQのために時間を頂いて，ありがとうございます。まずは自己紹介と，それからZalando STUPSプラットフォームについても紹介して頂けますか？
Sarnowski: 分かりました。私はZalandoのクラウドアーキテクトのTobias Sarnowskiです。Zalandoはベルリンを拠点とするオンラインのファッションプラットフォームで，欧州全域にいくつかのオフィスを持っています。私は2012年から，この会社で働いています。
STUPSは，Amazon Web Service(AWS)を利用する複数の自律型チームに，監査準拠の便利なPlatform-as-a-Service(PaaS)を提供する，ツールとコンポーネントのセットです。基本としては，IaaS上で独自のスタイルを持った抽象化を提供する，AWS用のアドオンですが，アプリケーションのデプロイのためのメタデータサービス，Dockerベースのデプロイメントツール，OAuth 2.0証明の秘密配布(secret distribution)なども備えています。
私たちのチームがSTUPSを一般公開したのは，Zalandoの技術部門がラディカルアジリティ(Radical Agility)を採用して間もない，2015年の春でした。ラディカルアジリティというのは，Daniel Pink氏の著書“Drive”で紹介されている，自律，習得，目的，さらには信頼といった概念を促進するような技術組織を運営するためのアプローチです。STUPSが成立するためには，ある意味で'ラディカルなアジリティ’が，前提条件として必要でした。技術チームが自律的な作業を始めるためには，そのようなものが必要だったのです。
InfoQ: すでに同種のものが存在する(Cloud FoundryやKubernetes, Cisco Mantlなど)中で，自身のプラットフォーム構築を考えた動機は何だったのでしょう？
Sarnowski: これは明確にしておきたいのですが，STUPSはスタンドアロンのプラットフォームではありません。AWS製品を全面的に活用することのできる，AWS上の軽量なアドオンなのです。ユーザが実行できることを制約したくはありません。私たちは，当社の社員がネイティブなAWSにフルアクセスできることを目標として，この開発を始めました。ですから制約をする部分は，継続的な内部監査ないし外部監査で追跡できない部分に限らなくてはなりませんでした。そして，嬉しいことに，私たちは成功を収めたのです！当社の社員は現在，自身のAWSアカウントを使って，ほとんど制限のない，管理者権限に近いアクセスが可能になっています。
InfoQ: STUPSをGCP(あるいは独立したプラットフォームとして)ではなく，AWS上で開発したのはなぜですか？
Sarnowski: クラウド機能と成熟度の面で，AWSが安全な選択肢だったからです。長所や癖もよく分かっていますし，ツールも充実していますから，自分たちで投資をする必要もなく，すぐに作業を開始することができました。
それに，AWSを評価していた時点のGCPは，まだ機能を充実させている段階だったのです。GCPには大きな可能性がありますから，今後はもっと注目するつもりです。
STUPSはAWSのアドオンですので，プラットフォーム独立になることはできませんし，それだけでは何もできません。Zalamndoで規定されたやり方でAWSを利用するには，それが役に立ちます。
InfoQ: mintはHashiCorp Vault, fullstopはGit Cave, SenzaはAnsibleというように，あなた方が’車輪の再発明’を行なっているという人たちもいますが，このようなツールを開発する背後にある，チームの考え方について説明してください。
Sarnowski: STUPSのツールはそれ自体，車輪の再発明ではなく，AWSの提供する機能をフルに活用するためのものなのです。例えばmintでは，秘密配布のためにAWSのIAMとS3をフル活用しています。これはAWSとS3を利用する方法としては極めて簡便でレジリエントですし，複雑なインフラストラクチャを維持する必要もありません。SenzaはAWS CloudFormationの簡単なラッパに過ぎません-これもまた，AWS製品のフルパワーを活用するもので，再発明ではありません。
私たちのAMIであるTaupageはSenzaと同じように，デプロイメントを行なう独自の方法を提供します。実はTaupage自体，私たちがDockerコンテナをオーケストレーションしている方法なのです。デプロイのアーティファクト形式としてDockerを使っていますが，コンテナ毎にそれぞれサーバを割り当てています。
AWSのエコシステムは，サーバ毎にひとつのアプリという動作モデルを中心としているので，Auto Scaling GroupやElastic Load Balancerの機能を自然な形でフル活用するためには，このような方法を取らなければならないことは分かっていました。一方のSenzaでは，イミュータブル(immutable)なデプロイ，という考え方を採用しています。私たちの方法では，アプリケーションの全バージョン毎にそれぞれ，新たなCloudFormationスタックを生成します。ソフトウェアのインプレース更新は行いません。このようなデプロイ方法によって，私たちは，非常に確定的な方法でBlue/Greenデプロイメントを実現しているのです。
InfoQ: STUPSの開発期間はどれくらいで，その間にいくつの製品版サービスが実行されたのでしょう？ZalandoのアプリケーションをSTUPSに完全移行する計画はありますか？
Sarnowski: STUPSの開発を始めたのは2014年末で，Zalandoの全チームが実システムで採用するようになったのは2015年の5月です。私たちがAWS上で運用しているマイクロサービスとステートフルなサービス(PostgreSQL, Cassandra, Spark, Kafka)もすべて，STUPS上で運用されています。
それから，そうですね，現在はすべてをSTUPS上で開発する計画です。
InfoQ: STUPSのWebサイトには“すべてのメンバが平等な権限を持つ”，“チームは自律的で，相応しいと思う技術を自ら選択することができる”ということが述べられていますが，技術的な面と組織面の両方から見て，これは本当に可能なのでしょうか？
Sarnowski: ラディカルアジリティを発表した時，私たちは同時に，チームの技術的ないし組織的ガイドラインとして，5つの”ゲームのルール”を採用しました。技術的な面では，これらガイドラインはすべて，私たちのサービスが提供する(旧Swagger 2.0，OpenAPI 2.0によって)明確に定義されたREST APIを必要とします。さらに私たちは，サービスディスカバリのためのDNSや，アクセス管理のOAuth 2.0といった，インターネットのスケールを可能にするツールもすべて利用しています。これによって全体的なアーキテクチャが，個々の技術的意思決定から独立したものになっているのです。
OAuth 2.0アーキテクチャをスケールアップするために，私たちは先頃，サービスをスケールする”Plan B”プロバイダを公開しました。私たちのサービスでは，すべてのサービスコールを認証し，承認する必要があるため，OAuth 2.0を徹底的に利用しています。これはOAuthインフラストラクチャにとって大きな負担になります。一般的なOAuthプロバイダの能力では，その負荷を適当な応答時間で処理することができません。すべてのマイクロサービスコールがカスケードされているため，OAuthが消費する数ミリ秒という時間が，あっと言う間に積み重なってしまうのです。
Plan Bアプローチでは，JWTを活用して分散的にトークンを検証することによって，トークン検証に関わる巨大な単一障害点(single point of failure)の発生を回避しています。これは同時に，tokeninfoエンドポイントをアプリケーションがローカルに(同一サーバ上に)展開することも可能にするので，ネットワークレイテンシ問題の回避や，全体的なロードの平準化という点でも有効です。
チーム内のコミュニケーションに関しては，私たちは現在，OKR(Objective-Key-Results)パターンを導入しています。導入段階ですが，すでに現時点でもチームは自律的です。私たちはコミュニケーションを価値観として重視しています。つまりチームとは，単に一緒に働くのではなく，協力し合う仲間なのです。
InfoQ: Randy Shoup氏など一部の人たちは，特定のチームが無闇にリソースを浪費しないようにするためには，ある種の経済的な支払取り消し(charge-back)モデルの実装が必要であり，最終的にはマイクロサービスの開発と維持を行なう独立したチームが必要である，と主張しています。この意見についてはどう思われますか？
Samowski: 実際に私たちがそうです。 マイクロサービスモデルで開発を始めてまだ長くないので，将来的に何が必要なのかは，正確には分かりません。ですが，API利用の内部的収支として考えれば，いくつかの点で非常に将来性があると思っています。現時点では，各チームが独立したSaaSプロバイダとして作業しています。将来的にはこれに課金機能が加わることになるでしょう。
InfoQ: コンプライアンスと監査の概念はSTUPSの重要な部分だと思いますが，その理由について説明して頂けますか？
Sarnowski: ひとつの面として私たちは，AWSに直接アクセス可能にすることによって，チームの自律性を最大化したいと思っていました。しかし上場ハイテク企業としては，金融面での規制に加えて，PCIやSOX，ドイツ法など，データの処理と保護に関する法律も遵守しなくてはなりません。監査役は，私たちが規制を遵守していることを知っておく必要があります。
このギャップを埋めるのは，最大の課題のひとつでした。最終的に考案したのは，開発フローと流暢(fluent)に統合されて，規制違反の発生をほぼリアルタイムに通知できるようなシステムです。これによって違反の発生を即時に認識し，対応することが可能になります。チームとはワークフローやツールの改善に関して常にコンタクトを取っていますので，規制によって作業が遅れることはありません。
InfoQ: STUPSに興味を持った人たちがコントリビュートするには，どうすればよいでしょう？プロジェクトとして支援を必要としていることはありますか？
Sarnowski: まずはSTUPSを多くの人たちに使って頂きたいですね。私たちは現在，STUPSを社外の人たちにも使いやすく，アクセスしやすいものにするため，特にカスタマイズ可能なエンタープライズインテグレーションに注力しています。ドキュメントの問題を見つけて報告してもらうことも，多くの人たちがSTUPSを利用する上で有用です。STUPSを使う上で支援が必要だったり，問題を見つけた場合には，遠慮なく問い合わせてください。
InfoQ: 今日はInfoQのためにお話を頂いて，ありがとうございました。最後に，読者に伝えておきたいことはありますか？
Sarnowski: STUPSは私たち自身が毎日の作業で直面している，非常にユニークかつ大規模な技術的課題を表したものであることを，ぜひ理解して頂きたいと思います。Zalandoはこの数年間で，“オンラインショップ”から“ファッションプラットフォーム”への移行という，非常に大きなシフトを行ないました。技術的な面からは，多様なイニシアティブをサポートするインフラストラクチャの構築とスケールアップを意味しています。その成果の多くをオープンソースとして公開すると同時に，ブログによる技術公開やカンファレンスでの講演も積極的に行なっています。技術チームにとって今は，エキサイティングな時です。
STUPSプラットフォームに関する詳しい情報は，同プラットフォームのWebサイトで，関連するコードはZalandoのSTUPS GitHubアカウントで，それぞれ入手可能だ。