Lagom - 新しいマイクロサービスフレームワーク

Akkaを開発するLightbend(先頃Typesafeから名称変更)が，同社のReactive Platformを基盤として使用したオープンソースのマイクロサービスフレームワークであるLagom(「ちょうどよい(just enough)」という意味のスウェーデン語)をリリースした。Play FrameworkやAkka製品ファミリに加えて，開発用としてConductRを使用しているのが特徴だ。デフォルトはメッセージ駆動型の非同期方式で，分散型CQRS永続化パターンとイベントソーシングを実装の中心に使用している。

同社CTOでAkkaを開発したJonas Bonér氏によると，Lagomと命名した理由のひとつは，マイクロサービスのマイクロ(つまりサイズ)を強調したくなかったことにある。小さいのではない，適切なサイズのサービスなのだ。

InfoQとのインタビューで氏は，新フレームワークを次のように説明してくれた。

InfoQ: Lagomの重要な機能は何だと思いますか？

Bonér: 私としては，他のマイクロサービスフレームワークに対してLagomを特徴付けているのは，次の部分だと思っています。

• 現存するマイクロサービスフレームワークのほとんどが，個々のマイクロサービスを簡単に構築できる点に腐心しています。それは難しいことではありません。Lagomはそれをマイクロサービスのシステムに拡張します。大規模なシステム構築には，分散システムの複雑性に直面する困難さがあるのです。
• 通信のデフォルトは非同期 – メッセージとストリームベース – で行われますが，必要ならば，同期型のRESTのようなプロトコルを使用することも可能です。
• 永続化は，デフォルトではイベントベース – イベントソーシングとCQRSを使用 – ですが，必要ならば，JPAやNoSQLデータベースなどもサポートします。
• 完全な統合化開発環境が用意されていて，100以上のマイクロサービスをコマンドひとつで管理することができます。すべてのサービスに対する自動ホットコード再ロードもサポートされていて，IDEなどのツールに組み込まれています。開発環境は本番環境に基づいている(ConductRを使用)ため，運用システムへのデプロイやスケールアップも直接サポートされています。

InfoQ: Lagomは自己主張型フレームワーク(opinionated framework)なのでしょうか？

Bonér: そのとおり，Lagomにはポリシがあります。私たちはAkkaやPlay Frameworkの開発を通じてたくさんのことを学びましたし，私たちのプラットフォームを使ってマイクロサービスを開発するユーザを見てきました – マイクロサービスということばが作られるよりも，ずっと前からです。

Lagomはリアクティブの原則(リアクティブ宣言で定義されている)に基づきます。リアクティブはLagomの設計に大きく影響し，その指針となっています。“正しいこと”が最初から簡単に実行できること，適切なデフォルト設定によるガードレール付きのアプローチを提供することが目標ですが，正当な理由があって，自分が何をしているのか理解しているのであれば，そこから逸脱することも可能になっています。

InfoQ: 具体的には，どのようなことを推奨しているのでしょうか？

Bonér: 簡単には触れましたが，改めて詳しく説明しましょう。Lagomが推奨し，簡略化しようとしている原則は，主に次のようなものです。

• シェアナッシング設計による真のアイソレーション: これはつまり，Lagomを使用したサービスが自律的かつ疎結合(アイソレーショントランスペアレント)である，ということです。いずれもレジリエントで柔軟であるために必要なものです。Lagomのマイクロサービスは，以下のものを基本としています。
  • Akka Actor―アクタモデルに基づいたシェアナッシングアーキテクチャによってアイソレーションを提供します。
  • Akka Cluster―マイクロサービスを構成する独立したサービスインスタンスのグループで，レジリエンス，共有，レプリケーション，スケーラビリティ，ロードバランシングを実現します。
  • ConductR―マイクロサービスの実行プラットフォームからランタイム管理までのアイソレーションを提供します。
• 責務の単一化: 古くからの原則である ”１つの処理に専念するプログラムを書く(write programs that do one thing and do it well)”―何十年も前のUnix哲学</1>―は，ただひとつの目的と明確に定義された小さな責務を持ち，他のプログラムと協調して動作するプログラムを書く上で，長く開発者の指針となってきました。その知見がこのマイクロサービス時代において，これまでにない価値を持つに至っているのです。大きさの問題ではありません。サイズやコード行数を連想させるマイクロサービスという表現は，実は極めて不適切なのです。Lagomでは，大部分のボイラプレートコードを取り除くことで，設計の簡素化を試みています。それによって，サービスの本質に集中することが可能になると同時に，非同期メッセージングやリクエスト/リプライ，連続的なストリーミングなどのいずれにおいても，それらを構成する明示的かつ型指定されたプロトコルの構築が容易になるのです。
• サービス自身によるデータ所有: それぞれのサービスはその振る舞いだけでなく，永続化に至るまでのデータも自身で管理します。Lagomの既定の永続化モデルは，イベントソーシングとCQRS―Akka PersistenceとCassandra―を使用するもので，スケール性に優れ，レプリケーションが容易である上に，完全なレジリエンスを実現しています。さらに，任意の時点からのイベントログの検査や再生が可能なことから，監査やデバッグにも適しています。JPAやHibernateのようなORM技術を使用する場合に悩まされる，これまでのオブジェクト-リレーショナルのインピーダンスミスマッチも回避することができます。とは言っても，当面の問題解決に最も適した永続化モデルを選択可能なこともマイクロサービスのメリットのひとつですから，つまりPolyglot(多国語) Persistenceなのです。
• すべての方法が非同期: Lagomでは通信もI/Oも非ブロックがデフォルトになっています。非同期処理はリアクティブシステム設計の基礎でもあり，リソースを効率的な利用によるコスト効率の向上が期待できること，システムリソースの共有に伴う競合(混雑状態)―これはスケーラビリティや低レイテンシ，高スループットを実現する上で，最も大きな障壁のひとつです―の最小化に有効であること，より疎結合な，可用性と柔軟性を備えた動的システムの実現が期待できること，などといった正当な理由もあります。マイクロサービスベースのシステムが今日の実世界におけるシステムの課題に対応するためには，このような事実を受け入れなくてはなりません。

Lagom最初のMVPは3月8日から，最初はJava用，続いてScala対応版が，GitHubで公開されている。