O’Reilly Software Architectureカンファレンスから学ぶ:初日

ThoughtWorksのソフトウェアアーキテクトであるNeal Ford氏とO'Reilly Mediaのソフトウェアアーキテクチャカンファレンスプログラム議長であるRachel Roumeliotis氏は、ソフトウェアアーキテクトは組織の技術とビジネスの行方に長期間に渡って影響を与える複雑な意思決定に関わる仕事であると言い、O’Reilly Software Architectureカンファレンスを開始を宣言した。現代のソフトウエアエンジニアリングにおいてこの事実にさまざまなトピックが組み合わさると、ソフトウェアアーキテクトという役割には継続的な学習と実践が求められる。

LightbendのCTOであり創業者でもあるJonas Bonér氏は‘blah, blah... microservices...blah, blah’と題した基調講演を行った。氏は従来のアーキテクチャとプラットフォームはすでに廃れており、一枚岩のアーキテクチャは多くのことをしようとするが、本当のビジネスドメインを効率的にモデル化しないと考えている。氏が言うには、‘マイクロ’という言葉はあまりよくないかもしれないが、単一責務という概念(Unixから着想を得たSRPの哲学からの)は価値があり、開発者は‘機動的で参照可能な’状態を保持することで‘ネットワークを取り込む’システムデザインをするべきだ。すべてのマイクロサービス型アプリケーションは分散システムに効率的に配置できるので、コミュニケーションの‘推測、謝罪、補償’という反復的なアプローチとアクションは価値あるパターンであり、それはSagaパターンと同じだ。Sagaパターンは、現実の世界ではよくある結果整合を正しく扱う。

‘マイクロ’サービスというネーミングは良くないかもしれませんが、単一責務という概念(from the Unixに着想を得たSRPの哲学を起源とする) はとても価値があります。

進化的アーキテクチャの進化の重要性についてはThoughtWorksのCTOであるRebecca Parsons氏が話をした。氏によれば、ソフトウェア開発産業は当初、低い期待値と共に始まり、一枚岩のアーキテクチャとSQLベースのデータストアが適していたが、アジャイルマニュフェストによって組織はより多くのことを求めるようになった。デザインパターンの導入と新しい設計、そして継続的統合という安全網によって、アーキテクトは継続的に“設計を進化”させ、需要を満たすことができるようになった。しかし、氏はデータの進化の一部としてデータのマイングレーションを実施するのは常に難しいと警告している。プロダクションでの稼働期間が長ければ長いほどデータの複雑さが増しているからだ。元のサービス志向アーキテクチャ(従来のSOA)は構成可能なシステムを構築する第一歩としては優れていた。そして、マイクロサービスによってこのコンセプトは次のレベルに移行するかもしれない。しかし、アーリーマジョリティとレイトマジョリティの組織はテクノロジーとテクニックが‘企業で使える状態’になっていると考えられる前に、“証明”を必要とする。

継続的統合のような実践の導入は進化的設計の安全網になります。

初日最初のブレイクアウトセッションでは、Pantheon SystemsのCTOであるDavid Strauss氏が‘デススターのセキュリティ’について話をした。デススターのセキュリティはシステムの一番外側を強化するという考えだが、ここが破られてしまうとすべてが崩壊する。この講演では、L2/L3のファイアウォール、ウェブアプリケーションファイアウォール、OWASPトップ10、DDoS制御などセキュリティの基本的なことや、ソフトウェアパッチを素早く当てることなどが話された。また、パスワード漏洩の回避について詳しく説明し、パスワードのソルティングやペパリング、パスワードストレッチング、多要素認証(MFA)が認証の点では、良いセキュリティを実現するために重要だと指摘した。また、認可については署名要求や活動トークンのような‘機能ベースのセキュリティ’が役に立つと言う。SELinuxが提供するような強制アクセス制御(MAC)はセキュリティを改善し、プロジェクトの当初から簡単に導入できる。

氏は機密情報や個人を特定できる情報を連合アイデンティティ管理サービスやペイメントゲートウェイのような信頼できるサードパーティに移譲することで内部でのセキュリティリスク管理を減らすことができると言う。‘データに触らないようにする’のも良いアプローチだ。‘Black Hole API’のようなパターンを使ってサービスから完全にデータを排除することで、将来、サービスのセキュリティが破られたとしても一度送信したデータは奪われなくて済む。データは動いている最中やエンドポイントでも守られる必要がある。HashiCorp VaultやSquareのKeywhizは安全な鍵管理などを実現するのに良いツールだ。また、氏は‘security by 不明瞭さによるセキュリティ’は有効な方法ではないと指摘している。組織は‘ホワイトハット’スタイルのハックイベントを開催してシステムがどの程度安全なのか検証してみるのが良い。

API ArchitectureとAPI Academyでディレクターを務めるMike Amundsen氏は‘Twelve Patterns for Hypermedia Architecture’と題して話をした。まず氏はハイパーメディアは概念であってプロダクトではなく、本質的にはWorld-Wide Web (WWW)の言語だ、と指摘した。人間はメッセージ経由でコミュニケーションをするが、意味を付加された要素とほかのエンティティへのリンクを持つハイパーメディアによって効果的なコミュニケーションが実現できる。クリストファー・アレグザンダーの古典である‘時を超えた建設の道’やGoFの‘デザインパターン’を参照しつつ、氏はメッセージにパターンを導入することはハイパーメディアとAPIシステム開発者にとって利点があると指摘している。

一般的なデザインパターンには次のような考えが含まれる。‘オブジェクトではなくメッセージを渡す’、モデルを共有するとサービス間が結合されてしまうので‘モデルではなく語彙を共有する’。オブジェクトを標準化するより表現や関係を標準化するほうが簡単なので‘リプレゼンタを使う’。メッセージを変換できるようにする。ユビギタス言語を持つことで人間や機械のAPIについての会話で何が話されているのかを明らかにするために‘プロファイルを公開する’。

‘基本原則パターン’は、次の通り。まず、‘無視すること’、つまり、寛容な読み取りサービスを作り、前方と後方の互換性を担保する。そしてポステルの法則を守る。次に‘転送すること’、つまり、ほかのダウンストリームのサービスのコンテンツを編集しないこと。‘MRUを提供する’、つまり、もっとも最近使われたアクションとドキュメントリンクを含むこと。‘冪等性’、つまり、アクションが冪等であるように設計すること。‘共有合意パターン’は、次の通り。‘関連を使う’、つまり、関連するリンクを返してナビゲーションを支援する。‘ナビゲーションを使う’。人間でも機械でもナビゲートできる方法を提供する。‘部分的サブミット’、つまり、段階的にデータのサブミットができるようにする。‘状態を見る’、つまり、機械が自律的に振る舞えるように状態を提供する。

次に、CognitectのバイスプレジデントであるMichael Nygard氏が、‘終わりという状態がないアーキテクチャ’というコンセプトについて話をした。氏によれば、組織は完全な‘安定した状態’のアーキテクチャを求め、(大抵はまずい発想の)変更サイクルで実現しようとする。このプロセスは現在の状態を決定し、最終的な状態を定義して計画を立てるために単純化される(“大抵の場合は３ヶ年計画として現れる”)。氏は大多数の組織は複雑系であり、実際には“安定した状態とは変化の波の重ね合わせ”だ。講演では、進化的なアーキテクチャを開発する上で支えになる8つのルールが示された。

1. 多数を受け入れる - 複数のシステム・オブ・レコードがあり、それぞれがビジネスのそれぞれのビジネスドメインを表している。
2. ダウンストリームの文脈化 - すべてのシステムが知る必要があるエンティティの数を最小化する
3. 粒度を意識する - 標準的なデータモデルを作らない
4. 脱中心化 - 中心のグループは制約を決めるべきで、ほかのチームに設計を押し付けてはならない
5. 障害ドメインの分離 - モジュール化の経済かつは高い。障害時の‘爆発半径’を制限できる。
6. データがアプリケーションよりも長生きする - ...
7. アプリケーションはベンダの統合よりも長生きする - 統合のポイントの間に適切な‘防腐レイヤ’を持つ。ヘキサゴナルアーキテクチャ(‘ポートとアダプタ’)の導入を検討して結合を最小限にする。
8. 見つけやすさ - 仕事の見える化(内部のブログやウィキ)、内部でのオープンソース文化の醸成

Nygard氏は草の根で‘エンジニアリング文化’を作ることに利点があると結論付けている。関連する組織、ビジネス、市場はすべて変化しているので、‘終わりの状態’に向けて設計をするべきではない。.

初日最後には、Sam Lambert氏が'Leading Simplicity'と題して講演をした。氏はGitHubのインフラ部門のシニアディレクターを勤めている。この数年に渡って、GitHubの技術的な基盤がどのように進化したのか、新しい競争力のある技術よりも安定している技術をどのようにして選んだのかについての物語だ。GitHubは単一のRuby-on-Railsアプリケーションで構築されており、1日に複数回配置される。GitHubのチームは‘リモートファースト’な働き方をしており、エンジニアは世界中にいる。インスタントメッセンジャー、メール、ビデオ電話でコミュニケーションをしている。組織の技術的なリーダーシップでは次のことに重きを置く。Unixに着想を得た、コードとツールに対する単一責務の原則、新しい技術を継続的に試す。ただし、‘イノベーショントークン’を賢く使う。そして、単純さ、だ。

複雑にするのは簡単です。そして、複雑さを取り除くのは難しいです。

また、ほかの価値についても説明をした。実践主義と予測しやすさに重きを置くこと。同社がMySQLを使ってほとんどのデータを保持しているのはこのためだ。ピアレビューと議論によってシステムの複雑さを避けること。“エレガンスが複雑なシステムに対するシンプルな解決策です。”そして、安定性が致命的に重要。

ニューヨーク市で開催されたO’Reilly Software Architectureカンファレンスの詳細はウェブサイトで確認できる。さらに、今年の10月18日から21日にかけてロンドンで追加のイベントが開催される予定。11月13日から16日にはサンフランシスコでも開催される。共に、プロポーザルの提出ページが開設されている。