フレクトのクラウドblog re:newal

http://blog.flect.co.jp/cloud/からさらに引っ越しています

Passkey のフィッシング耐性

こんにちは。エンジニアの山下です。

パスワードレス技術として Passkey が注目を集めていますが、この Passkey はフィッシング耐性を持つと言われています。今回は Passkey のフィッシング耐性を支える仕組みについて調査した結果を書きたいと思います。

Passkey と FIDO

そもそも Passkey は FIDO Alliance という団体によって定められた概念です。FIDO Alliance の 公式ページ では Passkey を以下のように定義しています:

Any passwordless FIDO credential is a passkey.

FIDO Alliance は FIDO (FIDO2) というパスワードレス認証の技術標準を定めており、この FIDO で使用されるパスワード以外のクレデンシャルを全て Passkey と呼ぶ、と定義は述べています。

実のところ、フィッシング耐性を持つように設計されているのは FIDO であり、単なるクレデンシャルに過ぎない Passkey にはいかなる力もありません。従って、以降は FIDO ではフィッシング耐性をどのように実現しているのかが話の主題となります。

FIDO については 公式ページ にある以下の画像を見るとイメージが掴みやすいと思います:

FIDO では Authenticator と呼ばれる認証デバイス(PC・スマホ・USB ドングルなど)を利用するのですが、上の画像は Authenticator としてスマホを利用した場合のログインの一連の動作を表しています。上記における USER APPROVAL および KEY SELECTED が Authenticator の利用箇所です。ブラウザを使って目的のサイトにアクセスした端末と Authenticator が連動して認証処理を実現している様子が表現されています。

Passkey は WebAuthn とセットで語られることも多いですが、この WebAuthn は FIDO の仕様の一部です。FIDO は全体の挙動を定めるプロトコルの CTAP と、その CTAP においてブラウザ・Authenticator の間の通信に使用するインターフェースとなる JavaScript API を定める WebAuthn で構成されています。

FIDO のフィッシング耐性

FIDO のフィッシング耐性は以下の3つの要素で成り立っているようです:

  • 機密情報のネットワークからの隔離
  • Origin Binding
  • Channel Binding

大まかに述べると、最初の「機密情報のネットワークからの隔離」は機密情報(パスワードや生体情報などのユーザが直接関与するシークレット)を守るためのアーキテクチャの原則で、それ以外は中間者攻撃 *1 に対抗するためのセキュリティ上のテクニックという構成になっています。

以下、それぞれについて順に説明していきます。

機密情報のネットワークからの隔離

古典的な認証システムでは、パスワードなどの機密情報を暗号化されたネットワークチャネルを通じてサーバに送信しますが、FIDO ではそもそも機密情報をネットワーク上に露出させる必要がないような設計になっています。

先述の通り、FIDO では Authenticator と呼ばれる認証用のデバイスを用いて認証を行いますが、機密情報の扱いは Authenticator の中で閉じるようになっています。具体的には以下の流れで認証を行います:

  1. サーバがブラウザにチャレンジ(認証要求)を送信する
  2. ブラウザが Authenticator にチャレンジを送信する
  3. Authenticator がユーザに機密情報の入力を促す
  4. ユーザが Authenticator に機密情報を入力する
  5. Authenticator がブラウザにチャレンジの結果を送信する
  6. ブラウザがサーバにチャレンジの結果を送信する

一方で、詐取対象となり得る以下のものはネットワークに晒されます:

  • Authenticator が生成するクレデンシャル
  • Cookie などに含まれる認証情報(セッションなど)

前者ですが、新規サービスの登録要求の際、Authenticator が認証に成功すると内部でクレデンシャルを生成します。このクレデンシャルは Authenticator がブラウザに送信する応答内容の作成等に使用されます。

しかしながら、このクレデンシャルは公開鍵暗号のキーペアで、その秘密鍵はやはりネットワーク上に露出することはありません。従って、利用している公開鍵暗号アルゴリズムが暗号学的に突破されない限り、安全性は機密情報と同程度になると考えらえます。

後者の認証情報については、残念ながら上記のフローの範疇では一切保護されないため、別途セキュリティ手法を導入するなどして保護する必要があります。後述の Channel Binding はその一例となります。

Origin Binding

Origin Binding とはクレデンシャルとチャレンジ要求元サーバの Origin を紐付けて、ある Origin からの要求で作成されたクレデンシャルは同一の Origin からの要求でなければ受け付けないようにする仕組みのことです。具体的には、ブラウザから Authenticator へリクエストを発行する際に Origin を同封し、Authenticator はその Origin を元に必要なクレデンシャルを判断するという流れになります。

フィッシングの代表的手法に、ユーザを本物そっくりの偽サイトへ誘導してクレデンシャルを詐取する中間者攻撃がありますが、この手の詐取は Origin Binding で防ぐことができます。外観がそっくりでも Origin は異なるため、プロトコルによって機械的に詐取の防止が可能です。

余談ですが、Origin Binding はそれなりに強いネットワーク構成上の制約になるため、緩和のための要望が GitHub で議論されているようです。

FIDO における Origin Binding

FIDO では Origin は WebAuthn の定める RP ID に格納して Authenticator に通知されることになっています。

MDN のサンプルコードがわかりやすいです。create() では publicKeyrp.id として Origin が渡されます:

const publicKey = {
  challenge: new Uint8Array([117, 61, 252, 231, 191, 241, ...]),
  rp: { id: "acme.com", name: "ACME Corporation" },
  user: {
    id: new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26]),
    name: "jamiedoe",
    displayName: "Jamie Doe"
  },
  pubKeyCredParams: [ {type: "public-key", alg: -7} ]
}

navigator.credentials.create({ publicKey })

get() では publicKeyrpId で Origin が渡されます:

const publicKey = {
  challenge: new Uint8Array([139, 66, 181, 87, 7, 203, ...]),
  rpId: "acme.com",
  allowCredentials: [{
    type: "public-key",
    id: new Uint8Array([64, 66, 25, 78, 168, 226, 174, ...])
  }],
  userVerification: "required",
}

navigator.credentials.get({ publicKey })

Origin の改竄可能性

1つ前のセクションを読めばすぐにわかりますが、Origin の指定は JavaScript で行います。これは WebAuthn が指定可能な Origin に幅を持たせているために生じた仕様だと思われます。*2

JavaScript はサーバからダウンロードしたプログラムに過ぎないので、攻撃者が悪意ある JavaScript を仕込んだ場合に Origin の改竄ができないかどうかが気になるところです。

結論から述べると、この rpId を改竄して Authenticator に送信しようとすると、リクエストはエラーとして処理されます。rpId が Origin を正確に表しているかどうかをブラウザが検証しているためです。この振る舞いは WebAuthn の仕様にも明記されています(太字による強調は本記事によるもの):

By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain. This default MAY be overridden by the caller, as long as the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin's effective domain.

つまり Origin を偽装するには、ブラウザ自体を侵害して悪意あるリクエストを発行可能にするか、ブラウザと Authenticator の間の通信に割って入るかのいずれかが必要になります。どちらも実施するにはそれなりの手間と技術が必要になりそうです。

Channel Binding

Channel Binding とは、認証処理を TLS コネクションに紐づけることで、攻撃者による認証情報のハイジャックを防ぐ仕組みです。

Channel Bindign では、認証で使用する TLS コネクションを一意に特定可能な ID を生成し、その ID が保証する正しい経路でのみ認証情報のやりとりを許可します。具体的には、以下の流れで通信が正しい経路で行われていることを検証します:

  1. 通信の送信側で送信に使用する TLS コネクションの ID を生成する
  2. 通信の送信側から ID と改竄防止のための署名を受信側に送信する
  3. 通信の受信側で受信に使用した TLS コネクションの ID を生成する
  4. 通信の受信側で受信した ID と生成した ID が一致することを検証する

この検証によって中間者攻撃の検出が可能です。中間者攻撃を受けている場合、通信は以下のような構成になります:

Authenticator ⇄ ブラウザ ⇄ 攻撃者 ⇄ サーバ

攻撃者がブラウザとサーバの間に入ったことで、ブラウザ(送信側)とサーバ(受信側)が使用する TLS コネクションの ID が一致しなくなります。

また、認証情報が使用可能な通信経路が限定されるため、攻撃者が Cookie の詐取などで得た認証情報を別経路で使用することができなくなるという利点もあり、セキュリティにおいてはかなり恩恵の大きい機能です。このあたりの具体的な話については FIDO に詳しく述べられているので、興味がある方はそちらを参照していただければと思います。

FIDO における Channel Binding

FIDO では Token Binding を利用して Channel Binding を実現するように仕様が規定されています。Token Binding とは TLS コネクションを一意に特定可能な ID を生成する技術の標準仕様です。ただし、様々なユースケースを考慮して Channel Binding の利用は任意とされています。

Token Binding に関するデータの実態は WebAuthn で CollectedClientData として定義されているオブジェクトの tokenBinding パラメータの中に格納されます。この CollectedClientData はブラウザから取得した情報を元に Authenticator が作成し、それがブラウザ経由でサーバへ渡る形になります。Authenticator が作成するのは、同時に署名を作成してデータの改竄を防ぐためです。

CollectedClientData は clientDataJSON というパラメータとして送信されます。MDN のサンプルコードを見ると、Authenticator からブラウザへの応答の中に clientDataJSON が含まれていることがわかります:

navigator.credentials.create({ publicKey }).then((publicKeyCredential) => {
  const response = publicKeyCredential.response;

  // Access attestationObject ArrayBuffer
  const attestationObj = response.attestationObject;

  // Access client JSON
  const clientJSON = response.clientDataJSON;

  // Return authenticator data ArrayBuffer
  const authenticatorData = response.getAuthenticatorData();

  // Return public key ArrayBuffer
  const pk = response.getPublicKey();

  // Return public key algorithm identifier
  const pkAlgo = response.getPublicKeyAlgorithm();

  // Return permissible transports array
  const transports = response.getTransports();
});

つまり、全体の流れとしては以下になります:

  1. ブラウザが Authenticator に Token Binding の情報を送信する
  2. Authenticator が clientDataJSON とその署名を作成する
  3. Authenticator がブラウザに clientDataJSON とその署名を送信する
  4. ブラウザがサーバに clientDataJSON とその署名を送信する
  5. サーバが独自に Token Binding の情報を作成し clientDataJSON の中に含まれる tokenBinding が正当であるかを検証する

少なくともこのレベルの視点においては、なかなか堅牢そうな造りに見えます。

Token Binding の実際

突然ですが、悲しいお知らせをしなくてはなりません。WikipediaToken Binding に書かれている以下の一文をお読みください。

Only Microsoft Edge has support for token binding.

恐ろしいことにほとんどのブラウザが Token Binding をサポートしていないのです。状況は芳しくなく、ChromiumGroups には Token Binding に関する実装コードを全削除した旨が記録として残されていたりします。

MDN でも tokenBinding パラメータの横に Deprecated を示すゴミ箱アイコンが表示されており、Token Binding は廃れていく方向にあるように見えます。

念のため Google ChromeSafariMicrosoft Edge で Passkey を使用した際に clientDataJSON がそれぞれどうなるのかを試してみました。なお、サーバは Auth0 を使用しています。

結果は以下の通りです:

{
    "type": "webauthn.get",
    "challenge": "WBlOWP_-Mkf6Z-fbLbnK0gUgYRD-lBPltbGTFk_GNlY",
    "origin": "https://test-dyamashita.jp.auth0.com"
    "crossOrigin": false
}
{
    "type": "webauthn.get",
    "challenge": "b0SV24IqAAUOaMXuXPvQegQ_fmgOfTKsl79CCiZvIMM",
    "origin": "https://test-dyamashita.jp.auth0.com"
}
{
    "type": "webauthn.get",
    "challenge": "wCjiCpMCXCa9oQWT1pFoKMXKXyFG5yIAqtvHFGit6DQ",
    "origin": "https://test-dyamashita.jp.auth0.com",
    "crossOrigin": false
}

Token Binding をサポートしているはずの Microsoft Edge ですら tokenBinding パラメータがないという結果になりました。やはり現状では Passkey の Channel Binding は機能していない状態になってしまうようです。

FIDO は ブログ で Channel Binding の利用によって克服される問題について語っていますが、これらについては別途対策を取る必要があるということになりそうです。

まとめ

今回調べてわかった結果をまとめます:

  • 機密情報のネットワークからの隔離
    • 機密情報は Authenticator の中で扱いがとじているので詐取は困難
    • Authenticator が生成するクレデンシャルも公開鍵暗号により詐取は困難
    • ただし認証情報自体の詐取に対する効力はなさそう
  • Origin Binding
    • 外観の類似などの人間の勘違いを基礎にした詐取は防止できる
  • Channel Binding
    • Passkey では機能していない

ちなみに、上記は WebAuthn を使ってフロントエンドを実装する際に特別注意を払わずとも自動的に有効になります。

WebAuthn が絡むもので現在機能しているのは Origin Binding のみですが、Origin Binding に使用するパラメータ rp.id ないし rpId は特に指定せずともデフォルトで現在の Origin が自動で適用されるようになっているためです。MDN に記載があるので、詳しくはそちらを参照ください。

また Channel Binding も Authenticator から受け取った clientDataJSON をそのままサーバに返すのみでよいので、必要な実装を行えば自然に有効になるようになっています。もっとも、先述の通り、現在は Token Binding のサポート状況のため機能していませんが ... 。

FIDO について色々調べている中で Channel Binding について熱く語られている記事を目にしていたため、実際には Channel Binding が機能していない点には非常に驚きました。Origin Binding でも中間者攻撃に対抗できるとはいえ、Channel Binding による恩恵はかなり大きいので、今後のアップデートで代替方法が検討されることに期待したいです。

なお、上記で困難と書いている内容についても、当然ながら、ソーシャルエンジニアリングなどによって突破される可能性はあります。安心し切ってセキュリティホールを見落とさないようにしましょう。(自戒

以上です。最後までお読みいただき、ありがとうございました。

*1:厳密には中間者攻撃以外の攻撃もカバーしています。特に Channel Binding は詐取した認証情報を別のコネクション上で使用することを阻止するため、より広範な攻撃を阻止できます。

*2:どのように幅を持たせているかについては こちら に明記されています。

InfinispanをRedisの代わりに使ってWebサーバーをHA構成する

皆さんこんにちは。エンジニアの佐藤です。今回はメモリキャッシュのお話です。

Redisはポピュラーなメモリストレージではあるが。。

Webアプリケーション開発者の方々なら、Redisを知らない人はいないでしょう。メモリストレージの定番として、筆者が認識し始めたのは10年ぐらい前でした。無料で利用可能で、Dockerコンテナで手軽にデプロイできます。今ではクラウドベンダーはほとんどRedisをSaas提供しており、ローカル開発環境からクラウドの本番環境にそのままま乗せ替えできる点も便利です。

しかし、問題はお値段です。Redisは当然、CPUを占有します。CPUは高価なリソースです。さらに頭が痛いのが、高可用性(HA)構成です。RedisをHA構成しようと思ったら、待機系を用意しなければならず、費用は2倍です。つまり、WebサーバーのHA構成と合わせてCPUを4つ運用する必要があります。昨今は様々な調達方法がありますので実際は単純ではありませんが(本稿執筆中にAWSからElastiCache Serverlessなるアナウンスもありました)、Redisが本質的に高価なストレージであることに変わりはありません。

Infinispanという選択肢が

そんな折、Infinispanなるものの存在を知りました。RedhatJBossの一部としてオープンソースで開発しているもので、商用ライセンスはDataGridとして販売されています。業務要件でこのInfinispanを展開する機会があり、調べて試しているうちに、これはRedisの代わりに使えるんじゃないかと思い始めました。(ただし、仕様は異なります。InfinispanはRedis RESP3エンドポイントもありますが、サポートされるコマンドは限定的です。)

Infinispanの特徴は、HA構成をサポートしていながら、クラスタノード同士は対等な、マルチマスター構成である点です。(もちろん、主系待機系構成のRedisとどちらが良いという問題ではありません。)普段は調達リソースの100%のパフォーマンスを期待し、障害時は半分で我慢する、という構成が取れます。

そこで今回は、このInfinispanをWebサーバーのメモリストレージとしてHA構成する方法をご紹介したいと思います。何かの参考にしていただければ幸いです。

まず最初に、作戦を立てる

Infinispanは高機能なので、様々な構成が可能です(興味のある方は文末の余談「高機能だが知名度が低く、難解なInfinispan」をお読みください。)その分迷いやすく、結局どうすれば良いのかわからなくなりがちです。そこで今回は最初に作戦を立てて、参考知識を収集していきます。

今回立てた作戦は以下のようなものです。

  • 基本的にHA構成のWebサーバーです。
  • Webサーバーは、自身のノード(クラウドインスタンスなどに相当)のInfinispanノードにアクセスします。
  • これが2ノード
  • 2つのノードに配置されたInifispanノードは、ひとつのクラスタとして動作します。片方のInfinispanノードに対する変更は、他方のInfinispanノードにも反映されます。
  • クライアントはロードバランサーを経由してこのWebサーバーを見ており、あたかも1台のサーバーがあるかのように見せられています。

Infinispanはポート11222をREST APIエンドポイントとして使います。このエンドポイントはノード内部専用で、認証は設定しません。ポイントは赤点線の中で、Infinispanノード同士は「ノード間通信」と「障害検知」の2つのコネクションでつながっています。前者はポート7800、後者はポート57800です。(文末の余談「Infinispanのポートはどうやって決まっているのか」参照)

この作戦自体は、特に不自然なものではなく、平易に理解していただけると思います。

この作戦を展開するもっとも簡便な方法は、KubernetesのSidecarの利用です。こうするとノード間通信はKubernetesクラスタの内部ネットワークに隔離され、WebサーバーコンテナとInfinispanノードがひとつのPodに配置されます。今回はKubernetes環境にはCanonical MicroK8sをUbuntu 22.04LTSにインストールして使いました。

Infinispanを設定して、動かしてみる

次に、この作戦に従ってInfinispanを設定します。設定はXMLファイルを記述し、これをKubernetes ConfigMapでInfinispanコンテナに指定します。

まず設定のXMLファイルです。

<infinispan
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:infinispan:config:14.0 https://infinispan.org/schemas/infinispan-config-14.0.xsd
        urn:infinispan:server:14.0 https://infinispan.org/schemas/infinispan-server-14.0.xsd
        urn:org:jgroups http://www.jgroups.org/schema/jgroups-5.2.xsd"
    xmlns="urn:infinispan:config:14.0"
    xmlns:ispn="urn:infinispan:config:14.0"
    xmlns:server="urn:infinispan:server:14.0">
    
    <server xmlns="urn:infinispan:server:14.0">
        <interfaces>
            <interface name="public">
                <inet-address value="${infinispan.bind.address:127.0.0.1}"/>
            </interface>
        </interfaces>

        <socket-bindings default-interface="public" port-offset="${infinispan.socket.binding.port-offset:0}">
            <socket-binding name="default" port="${infinispan.bind.port:11222}"/>
        </socket-bindings>

        <endpoints>
            <endpoint socket-binding="default">
                <rest-connector />
            </endpoint>
        </endpoints>
    </server>

    <cache-container name="default">
        <transport stack="kubernetes"/>
        <distributed-cache name="cache01" owners="2" />
        <counters xmlns="urn:infinispan:config:counters:14.0" num-owners="2" reliability="CONSISTENT">
            <strong-counter name="counter01" initial-value="0" storage="VOLATILE"/>
        </counters>
    </cache-container>
</infinispan>

この内容は、infinispanの公開コンテナの内容から筆者が抜粋して作ったもので、以下のような内容です。

  • server/interface要素以下で、localhostネットワークの利用を設定します。
  • server/socket-binding要素以下で、ポート11222をエンドポイントに定めます。
  • server/endpoint要素以下で、REST APIをサービスプロトコルに定めます。

そしてcache-container要素の中でキャッシュストレージを定義していくわけですが、ここが難解です。

<transport stack="kubernetes"/>

これは、Infinispanノード間通信と障害検知に"kubernetes"という名称で既定で定義されている設定を使うという意味です。その定義はここにありますが、本ブログの範囲を超える内容になりますので、割愛します。

次のdistributed-cache要素は、クラスタ化された(つまり片方のInfinispanノードが障害となっても消えない)キーバリューストアです。本ブログでは、定義のみ紹介します。

次のcounters/strong-counterは、クラスタ化されたカウンターで、本ブログでこの後紹介していくものです。strong-counter(解説ブログはこちら)とは、クラスタ化されていて2ノード以上で維持されているストレージでありながら、その更新をトランザクションによって原子的に実行できるカウンターのことです。このカウンターの利用が、先の作戦図のような冗長構成でできることは、Infinispanクラスタが正常動作していることを確認する最も簡便な手段です。

このXML設定ファイルを利用して、作戦図にあるシステム構成を実現する定義ファイルは以下のようになりました。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ispn-config
data:
  infinispan.conf: |
    (ここにXML設定ファイルを貼り付け)
---
apiVersion: v1
kind: Service
metadata:
  name: test01-service
spec:
  type: NodePort
  selector:
    app: test01
  ports:
  - name: http
    port: 5000
    nodePort: 30001
    targetPort: http  
---
apiVersion: v1
kind: Service
metadata:
  name: infinispan-service
spec:
  ports:
  - name: jgroups
    port: 7800
    targetPort: jgroups
  - name: jgroups-fd
    port: 57800
    targetPort: jrogups-fd
  selector:
    app: test01
  type: ClusterIP
  clusterIP: None
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test01
  labels:
    app: test01
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test01
  template:
    metadata:
      labels:
        app: test01
    spec:
      containers:
      - name: test01
        image: localhost:32000/test01:20231128_03
        env:
        - name: INFINISPAN_REST_ENDPOINT
          value: http://localhost:11222
        ports:
        - name: http
          containerPort: 5000
      - name: infinispan
        image: infinispan/server:latest
        args: [
          "-c", "/usr-config/infinispan.conf",
          "-Djgroups.dns.query=infinispan-service.default.svc.cluster.local",
        ]
        ports:
        - name: infinispan
          containerPort: 11222
        - name: jgroups
          containerPort: 7800
        - name: jgroups-fd
          containerPort: 57800
        volumeMounts:
        - name: user-config
          mountPath: /usr-config
      volumes:
      - name: user-config
        configMap:
          name: ispn-config
      dnsConfig:
        options:
        - name: ndots
          value: "1"

一番重要なポイントは、Service「infninspan-service」を定めていることです。この定義により、Kubernetesの内部DNS名「infinispan-cluster-service.default.svc.cluster.local」により、Infinispanを含むPodのポート7800と57800の列挙ができるようになります。(KubernetesクラスタのCoreDNSプラグインを有効にしておきましょう。)

Webサーバー(test01コンテナ)はポート5000で着信待機し、localhost:11222で 手元の Infinispanノードと通信します。

InfinispanはConfigMapで作成されたvolumeをマウントし、これをinfinispan/serverコンテナの -c 起動オプションで指定することにより設定します。

Webサーバーの内容は、以下のような、Python Flaskを利用したごく簡単なものです。その機能は、ルートパスでアクセスされると、strong counter counter01を「原子的に参照し、加算する」処理を手元のInfinispanノードに対して行います。どのPodで実行されたかを示すために、Podのアドレスも付記することにします。このWebサーバーのエンドポイントはNodePort 30001で外部に公開します。

from flask import Flask
import requests
import os
import socket

INFINISPAN = os.getenv('INFINISPAN_REST_ENDPOINT', 'http://localhost:11222')

app = Flask(__name__)

@app.route("/")
def index():
    counter = requests.post(f'{INFINISPAN}/rest/v2/counters/counter01?action=increment').text
    addr = socket.gethostbyname(socket.gethostname())
    return f'{addr},{counter}'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

MicroK8sにインポートして、以下のようにWebサーバーの( HA対応の! )Webサーバーのエンドポイントを連続アクセスしてみましょう。

cmd="curl http://localhost:30001"; for i in $(seq 50); do $cmd; echo ""; sleep 0; done

結果は以下の通りで、ごく短時間で別のPodにアクセスした場合でも、正しくカウントアップされています。期待通りに動作していると考えて良さそうです!

10.1.89.54,162
10.1.89.55,163
10.1.89.55,164
10.1.89.55,165
10.1.89.55,166
10.1.89.54,167
10.1.89.54,168
10.1.89.54,169
10.1.89.55,170
10.1.89.54,171
10.1.89.55,172
10.1.89.54,173
10.1.89.54,174
10.1.89.55,175
10.1.89.54,176
10.1.89.55,177
10.1.89.55,178
10.1.89.54,179
10.1.89.55,180
10.1.89.55,181
10.1.89.54,182
10.1.89.55,183
10.1.89.54,184
10.1.89.55,185
10.1.89.54,186
10.1.89.54,187
10.1.89.55,188
10.1.89.55,189
10.1.89.55,190
10.1.89.54,191
10.1.89.55,192
10.1.89.54,193
10.1.89.55,194
10.1.89.55,195
10.1.89.54,196
10.1.89.55,197
10.1.89.55,198
10.1.89.55,199
10.1.89.54,200
10.1.89.54,201
10.1.89.55,202
10.1.89.54,203
10.1.89.55,204
10.1.89.54,205
10.1.89.55,206
10.1.89.54,207
10.1.89.54,208
10.1.89.54,209
10.1.89.54,210
10.1.89.54,211

今度はPodを落として実験してみましょう。

curl http://localhost:30001/

10.1.89.64,5

Podを確認します。

kubectl get pod -o wide

NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES
test01-f9c589f59-6vkbt   2/2     Running   0          12m   10.1.89.64   ip-172-31-0-83   <none>           <none>
test01-f9c589f59-krh6p   2/2     Running   0          12m   10.1.89.63   ip-172-31-0-83   <none>           <none>

先ほど返信した、IP 10.1.89.64のPodを落とします。

kubectl delete pod test01-f9c589f59-6vkbt

pod "test01-f9c589f59-6vkbt" deleted

再びアクセスすると、カウンタは正しくカウントアップされています!

curl http://localhost:30001/

10.1.89.65,6

振り返って、どうか

ここまでお読みくださりありがとうございました。

うまく当初の目標を達成しました。Webサーバーにメモリキャッシュは追加したいが、HAでRedisを構成するのは予算的に難しそうなケースにうまくフィットするかもしれません。

ただしInfinispanの学習・設定の負担はそれなりにあります。本家マニュアルポータルはこちらで、Dockerイメージの説明はこちらで、本ブログもこれらを参照していますが、不足している情報は周辺調査やソースコードを見て補う必要がありました。

「で、結局ミニマムHA構成はどうすれば良いのか?」と思われた時に、本ブログを参考にしていただければ幸いです。

(余談) Infinispanのポートはどうやって決まっているのか

Infinispanがどうやってポートを決めているのかは、簡単に見つかりません。筆者の邪推ですが、その昔、クラスタ内の一群の機材がファイアウォールを定めず自由に通信していた時代の文化のようにも感じられます。

その定義は、以下の部分に書かれています。

障害検知通信ポートは、ノード間通信ポートからのオフセット(ポート番号の足し算)で定義されているので、既定では7800 + 50000 = 57800になります。

JGroupsのマニュアルには、この障害検知ポートは設定されたポート範囲を定めることもできるとあります。これもまた、通信ポートがファイアウォールで制限される前の時代の文化のように、筆者には感じられます。

(余談) 高機能だが知名度が低く、難解なInfinispan

Infinispanは非常に高機能で、継続開発されており、ドキュメントも詳しく書かれています。今回はWebサーバーに併設する方法を採りましたが、単体のストレージクラスタとして構成することも可能で、遠隔バックアップ構成も可能なようです。

今回はKubernetesの例を紹介しましたが、クラスタノードディスカバリーにはAmazon S3などのオブジェクトストレージやJDBCを経由する方法もあり、AWS ECSではこちらの方法でクラスタを構成できます。

今回紹介していない有用な機能に「Java Transaction APIサポート」があり、XA(2フェーズ)トランザクションにも対応します。これによりメモリストレージとJDBCの更新の両方にまたがるトランザクション処理が構成できます。

年末調整保険料控除XML署名確認の顛末

みなさんこんにちは。エンジニアの佐藤です。今回は年末調整のお話です。

年末調整の時節、会社からは「保険料控除ではXMLを奨励」というアナウンスがありました。「エックスエムエル!」という言葉と共に新鮮な驚きが頭の中に広がりました。ええっ、XMLだって?あいつらまだ生きていたのか!そう、コンピュータ同士の相互通信データフォーマットとして、XMLは時代遅れなのです。現在の主役はとっくにJSON。何を今更XML

しかし、筆者はXMLは嫌いではありませんし、それなりに知識もあります。(昔話に興味のある方は、末尾の「昔話」をご覧ください。) 保険業社が発行するXMLがどんなものか、大きな興味をもってファイルを開いてみました。

保険料控除のXMLはどういう構造になっているのか

ざっくり言うと、以下のような構造になっています。

<文書>
  <保険情報詳細/>
  <署名情報/>
</文書>

その仕様は「源泉徴収票等オンライン化に関する仕様書」として国税庁が配布しています。これ自体は特に難解なわけではなく、保険業社や支払い金額など、年末調整の保険料控除の書類に記入していた項目が書かれているだけです。

難しいのは(そしておもしろいのは)、署名情報の部分です。概要は以下のようになっています。

<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Id="...">
    <dsig:SignedInfo>
        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
        <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <dsig:Reference URI="#(保険情報詳細データへのポインタ)">
            <dsig:Transforms>
                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                <dsig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
            </dsig:Transforms>
            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <dsig:DigestValue>(保険情報詳細データのダイジェスト)</dsig:DigestValue>
        </dsig:Reference>
    </dsig:SignedInfo>
    <dsig:SignatureValue>(署名データ)</dsig:SignatureValue>
    <dsig:KeyInfo>
        <dsig:X509Data>
            <dsig:X509Certificate>(署名者の証明書)</dsig:X509Certificate>
        </dsig:X509Data>
    </dsig:KeyInfo>
</dsig:Signature>

内容はこうです。まず保険詳細情報の部分がXML文書としてバイナリデータになり、ダイジェストが計算されます。そしてこのダイジェストが署名者の秘密キーで署名され、署名データとなります。この署名データを署名者の証明書に含まれる公開キーで検証することで、証明書の発行者(=署名者)が署名した内容に改ざんがないことが確認できるのです。

証明書はbase64形式ですが、復号すると署名者は「Registrar of Tokyo Legal Affairs Bureau, Japanese Government」となっていました。この署名者として署名できるのは、署名者に対応する秘密キーを手にした者だけに、厳密に制限されます。 つまりこれは、東京法務局が署名した公文書で、法律上の扱いはともかく、その性質は住民票や車検証といった身近な公文書と完全に同じです。(たったこれだけのテキスト断片にそんな価値があるなんて、なんだかワクワクしてきませんか。)

この保険業社発行のデータは、もちろんその有効性を確認してから発行されていると思います。疑うわけではありません。しかし、エンジニアとしてその真正性を確認したいと思った筆者は、署名の検証を手元でやってみようと思い立ちました。

ただ、これが結構、険しい道だったのです。結論はこうです。署名検証は可能で、署名は正しかったです。しかしこれを確認する手順は、ライブラリで一発では決してなかったのです。Java言語とPython言語で、2つの保険料控除XMLの署名を確認しましたが、確認のためにはそれなりの知識とプログラム調整を要しました。 ひょっとしたら同じ問題に遭遇している方がいらっしゃるかもしれないと思い、ここにその顛末を紹介させていただきます。

Java言語の場合

Javaの場合は、JDKXML署名検証のための機能が実装されており、その使い方はOracleの以下のサイトに書かれています。

XML Digital Signature API

ただし、結構な分量があり、その内容もかなり専門的です。幸い以下のGithub公開レポジトリに、この文書で解説されているサンプルコードが取りまとめられており、筆者もこれを動かしてみることから始めました。

https://github.com/jknecht/xml-signature-validation

しかし、、そのまま動かすと以下の例外になってしまいます。

javax.xml.crypto.MarshalException: It is forbidden to use algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 when secure validation is enabled

そういえば署名情報を見た時から、悪い予感がしていたのです。SHA1アルゴリズムは、強行突破する計算量が現在のコンピュータの速度と比較して不十分と業界で認識され、非奨励となっていたのです。しかし今回はダイジェストがSHA1で作られているため、このアルゴリズムを動かさざるを得ません。

その手順は巷に幅広く解説されていますが、以下のような手順です。

まず既定のjava.securityファイルを回収します。筆者の場合は以下のディレクトリにありました。

/usr/lib/jvm/java-17-amazon-corretto/conf/security/java.security

次に、この内容を以下のように変更して、SHA1の禁止措置を解除します。

# 以下が禁止措置を解除した元々含まれていた項目
# disallowAlg http://www.w3.org/2000/09/xmldsig#sha1,\
# disallowAlg http://www.w3.org/2000/09/xmldsig#rsa-sha1,\

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    disallowAlg http://www.w3.org/2000/09/xmldsig#dsa-sha1,\
    disallowAlg http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    minKeySize RSA 1024,\
    minKeySize DSA 1024,\
    minKeySize EC 224,\
    noDuplicateIds,\
    noRetrievalMethodLoops

これをプログラム開始時に以下のコマンドライン引数で指定すれば、SHA1が使えるようになります。

-Djava.security.properties=${workspaceFolder}/java.security

さあこれで動くようになったでしょうか?残念ながらそうではありません。続いて以下の例外となりました。

Caused by: com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID ...

もういきなりわかりません。IDって。。??デバッガでJDKのコードフローを辿っていくと、URIリファレンスの解決に失敗した、と言うふうに読めます。そこで元のXMLを眺めていると、該当しそうな場所が見つかりました。冒頭に紹介した署名情報の以下の部分です。

<dsig:Reference URI="#(保険情報詳細データへのポインタ)">

このURIをIDとして設定しているのは、ルート要素の以下の部分です。

<TEG810 xmlns="http://xml.e-tax.nta.go.jp/XSD/kyotsu" xmlns:gen="http://xml.e-tax.nta.go.jp/XSD/general" xmlns:kyo="http://xml.e-tax.nta.go.jp/XSD/kyotsu" VR="1.0" id="TEG810...">

ははぁ、これは保険情報のXMLノードクエリ失敗だなと思って調べてみると、XML DocumentにはID解決する属性を指定する必要があるという巷情報に行きつきました。

https://stackoverflow.com/questions/3423430/java-xml-dom-how-are-id-attributes-special

Githubソースコードに以下のように追記します。

Document doc = dbf.newDocumentBuilder().parse(
        new FileInputStream(fileName));
Element x = doc.getDocumentElement();

// 追加部分
doc.getDocumentElement().setIdAttributeNS(
    null, 
    "id", 
    true);

すると、、、以下のように表示され、署名検証が成功しました!

Signature passed core validation

試しに保険詳細情報(金額など)や署名の内容を1文字変更して検証してみましたが、正しく検証エラーとなります。A社とB社両方のXMLで署名を確認できました。

Python言語の場合

Pythonの場合は。。と思って巷ライブラリを確認した筆者は、大きなショックを受けました。ほとんど以下の一択なのです。

https://xml-security.github.io/signxml/

しかも、サンプルコードがありません。公式ドキュメントに書かれているサンプルはわずかにこれだけです。

https://xml-security.github.io/signxml/#verifying-saml-assertions

XMLVerifier.verifyの説明を読み込むなどして、以下のコードを書き起こしました。(最終コードは本項目の末尾をご覧ください。)

from lxml import etree
from signxml.verifier import XMLVerifier, SignatureConfiguration
from signxml.algorithms import DigestAlgorithm, SignatureMethod

xmlData = None

with open("a.xml", "rb") as fh:
    xmlData = fh.read()
    x = etree.XML(xmlData, None)
    el = x.find(".//ns:X509Certificate", namespaces={"ns": "http://www.w3.org/2000/09/xmldsig#"})
    cert = el.text

verifier = XMLVerifier()
assertion_data = verifier.verify(
    xmlData, 
    x509_cert=cert
).signed_xml
s = etree.tostring(assertion_data)
print(s)

証明書データをあえて事前に回収しているのは、verifyメソッドの説明に以下のように書かれているからです。

If left set to None, requires that the signature supply a valid X.509 certificate chain that validates against the known certificate authorities.

東京法務局が今回の証明書に対応するルート証明書を発行しているのか、本稿執筆時点では確認できませんでしたので、システムCAにそれを収録する代わりにCAチェックを回避する方法を選びました。

実行すると、Javaの時にも遭遇したあのエラーです。

signxml.exceptions.InvalidInput: Signature method RSA_SHA1 forbidden by configuration

以下のようにして有効化します。

verifier.verify(
    xmlData, 
    x509_cert=cert,
    expect_config=SignatureConfiguration(
        signature_methods=frozenset({
            SignatureMethod.RSA_SHA1
        }),
        digest_algorithms=frozenset({
            DigestAlgorithm.SHA1
        })
    )
)

ここまで修正して、B社のXMLは検証成功しました!例によって内容を変更して確認しましたが、正しく検証できているようです。

しかし、、A社のXMLでは以下の例外になっていまいます。

signxml.exceptions.InvalidSignature: Signature verification failed: bad signature

こんなことって。。 (あるんですよね、こういうことが。これが言わば、ソフト開発技術者業務の難所だと筆者は思います。特に今回のように暗号アルゴリズムを使う場合は、数多ある設定が完全に想定通りでないと、このような冷たいエラーから抜け出すことができないのです。)

しかし、B社のXMLでは署名検証成功しているので、この差分を詰めていけば、絶対に正解に辿り着くはずです。まずXMLの中身の確認から入りました。署名情報部分に以下のような違いがありました。

A社(失敗)

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" ...>

B社(成功)

<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" ...>

XMLに詳しい方なら分かると思いますが、この2つのXMLは、この部分だけを見れば、同値です。要素の名前が違うじゃないかと思われるかもしれませんが、B社XMLの「dsig」の部分は名前空間のプレフィクスであり、本当の名前空間識別子は「xmlns:dsig」属性で指定されいる「http://www.w3.org/2000/09/xmldsig#」の方なのです。

念のためA社XML名前空間をB社形式に合わせてみましたが、エラーは解消しませんでした。

頭を総動員して考えられる可能性を探っていきます。

そもそもXMLの署名検証とは、以下のような過程で行われるものです。(他の方式もありますが、今回の場合です。また、今回はA社XMLとB社XMLで方式は共通です。)

  1. SignedInfoの内容 から作った署名情報を、証明書の公開キーで復号したSignatureValueの署名データで検証する。
  2. Reference ID指定された要素からSignature要素を除いた部分の内容の ダイジェストを計算する。
  3. ダイジェストをDigestValueと比較する。

SignedInfoの中にはダイジェストが含まれていますので、こうすることでXML全体の内容保証ができるのです。問題は、SignatureInfoや、Reference ID指定された要素はXMLテキストであり、先ほど紹介したように、その内容に表現の多様性があることです。一方でデジタル署名は内容が完全に一致するバイナリデータに対する署名ですので、XMLテキストはそのままでは署名データとしては使えないのです。そこでcanonicalizeというプロセスが登場します。CanonicalizationMethod要素を見ると、その手順の識別子が定義されています。

しかし、canonicalize手順の識別子はA社とB社で全く同じです。何が問題なのでしょうか。

次に筆者が思いついたのは、署名検証データとして持ち込まれるSignatureInfoの 完全な文字列情報の 確認です。これはPythonデバッグ情報を出力させることで行えます。

出力した文字情報は、以下のようになっていました。(括弧内は固有情報なのでマスクしています。)

<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:gen="http://xml.e-tax.nta.go.jp/XSD/general" xmlns:kyo="http://xml.e-tax.nta.go.jp/XSD/kyotsu"><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod><Reference URI="#(ID情報)"><Transforms xmlns=""><Transform xmlns="" Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform><Transform xmlns="" Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></Transform></Transforms><DigestMethod xmlns="" Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod><DigestValue xmlns="">(保険情報詳細データのダイジェスト)</DigestValue></Reference></SignedInfo>

A社のXMLJavaでの署名情報検証には成功しています。その時のSignedInfo文字列はどうなっていたのでしょうか。

その出力手順は複雑で、まず以下のようなlogging.propertiesファイルを用意します。

handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = FINER
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
org.jcp.xml.dsig.internal.level = FINER
com.sun.org.apache.xml.internal.security.level = FINER

次にこれをjava起動パラメターで指定します。

-Djava.util.logging.config.file=${workspaceFolder}/logging.properties

出力されたのは、以下のような文字列でした。

<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:gen="http://xml.e-tax.nta.go.jp/XSD/general" xmlns:kyo="http://xml.e-tax.nta.go.jp/XSD/kyotsu"><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod><Reference URI="#(ID情報)"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform><Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></Transform></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod><DigestValue>(保険情報詳細データのダイジェスト)</DigestValue></Reference></SignedInfo>

Pythonの方にだけ、「xmlns=""」という、空のXML名前空間指定が付いています。これは、ライブラリの処理としては誤りで、バグと考えても良いかもしれません。

幸い、この空のXML名前空間指定を文字列編集で除去するオプションがライブラリにありました。これはどこにも解説されていない内容で、筆者がライブラリのソースコードを読んで掘り出したものです。

verifier = XMLVerifier()
verifier.excise_empty_xmlns_declarations = True

最終的なPythonプログラムは以下のようになりました。

from lxml import etree
from base64 import b64decode
from signxml.verifier import XMLVerifier, SignatureConfiguration
from signxml.algorithms import DigestAlgorithm, SignatureMethod
import logging

logging.basicConfig(encoding='utf-8', level=logging.DEBUG)

xmlData = None

with open("a.xml", "rb") as fh:
    xmlData = fh.read()
    x = etree.XML(xmlData, None)
    el = x.find(".//ns:X509Certificate", namespaces={"ns": "http://www.w3.org/2000/09/xmldsig#"})
    cert = el.text

verifier = XMLVerifier()
verifier.excise_empty_xmlns_declarations = True

assertion_data = verifier.verify(
    xmlData, 
    x509_cert=cert,
    expect_config=SignatureConfiguration(
        signature_methods=frozenset({
            SignatureMethod.RSA_SHA1
        }),
        digest_algorithms=frozenset({
            DigestAlgorithm.SHA1
        })
    )
).signed_xml
s = etree.tostring(assertion_data)
print(s)

このプログラムで検証すると、A社のXMLも検証OKとなり、内容改ざんの検出も期待通りでした!

振り返りと、昔話と、雑談

様々な問題がありましたが、なんとか目的を達成しました。最後までお読みいただきありがとうございます。

いろいろ調べながら感じたのは、XML署名が業界的にマイナー技術であり、とにかく文献が少なくて古いことです。時代の流れは着実にJSON/JWTであり、XMLは旧技術なのです。しかしXMLで決まっていることは仕方がないし、一度決まった業務仕様は長い間生きながらえます。知識の力で何とかつなぐのがエンジニアの仕事です。

今から20年ほど前、XMLが大きな注目を集めたことがありました。Microsoft.NET Framework 1.0を発表し、その目玉機能としてアピールしたからです。商売の話はさておき、筆者も、あのとき、紙書類の階層構造と、バイナリメッセージフォーマットの中間にある、コンピュータでクエリできる構造化された共通テキストフォーマットであるXMLに大きな可能性を感じていました。

そんなXMLはどうして主流になれなかったのか?筆者の知る限り、現在XMLが使われているのは、Mavenなどの設定ファイルと、SOAPプロトコルと(Salesforce SOAP APIは現役です!)、SAML査証だけです。XSLなどのスキーマ定義やXSLTなどのHTMLへのデータ変換に至っては、ほとんど見かけなくなりました。その理由はおそらく、仕様を膨らませ過ぎたことにあるのではないかと筆者は思っています。そのため難解になり敷居が上がり、開発工数と戦うエンジニアの方々からは遠ざかってしまったのです。XMLが果たすはずだった役割は、今ではほぼJSONが代わりに果たしているように筆者には思えます。

このような経緯はあれど、ようやく当時の技術が実用化されて手元にあるのだと思うと、年末調整保険料控除XMLシステム開発に携わったエンジニアの方に感謝したい気持ちになりました。

Spring Boot Web JPA は GraalVM でメモリ節約

こんにちは。エンジニアの佐藤です。今回はGraalVMのお話をさせていただきます。

きっかけは相談から

先日他プロジェクトの方から「Webサーバーのリクエストが不思議なタイムアウトをしているが、どうしてだろうか?」と相談を受けました。話を聞いていると、メモリ(主記憶)利用超過が疑わしいと思いました。メモリは古来からある問題で、瞬間的にでも超過すると、サーバーはOS(通常はLinux)によって実行停止措置となってしまいます。今回の場合、そのリミットは1GB。仮想メモリはありませんので、この制限を踏み越えればアウトです。

Spring Boot Data JPAの凄まじいメモリ使用量

インタビューによると、利用しているフレームワークはSpring Boot。長い歴史を持つJava言語のポピュラーなフレームワークです。しかし筆者はこのとき「どうしてNodeJSとかにしなかったのだろうか」と思っていましました。なぜならばこのSpring Boot、「Data JPA」を使うと、起動がものすごく重くなるからです。数年前に何とか速くならないものかと頑張ったこともあったのですが、どうしようもない降参だと思っていました。メモリ利用量も多く、ごく単純なアプリケーションでも300MB以上のメモリを消費するとされています。今回のリミットの1GB(=1000MB)と比較すると、何とも心配な消費量です。

そう言えばGraalVMがあった

そう言えば。。Java界隈での最近の話題と言えば、GraalVMです。これ自体は以前からあったのですが(2011~)、今年初夏にOracleが無償利用条件を緩和し、再び注目を集めています。Spring FrameworkでもSpring NativeとしてSpring Boot v3からサポートされています。GraalVMのホームページによると、起動時間の短縮とメモリ利用量 節約に効果があるとされています。今回のお悩みにミートしそうです。

しかし、(古い話ですが)Java言語は何といっても動的コンパイルの元祖です。四半世紀も続いたパラダイムを事前コンパイルにシフトするなど、可能なものでしょうか?そこはもちろんJavaの本家Oracleが頑張っているので大丈夫と信じたいですが、Javaの歴史は古いので、古いライブラリがサポートされていない可能性はどこまでもあります。一方、Javaと多くのアイディアを共有するMicrosoft .NETはネイティブイメージコンパイラNGenを10年以上前からサポートし、Microsoft製品のインストール経過で利用されているのを目にしていました。

この機会に、試してみることにしましょう。

ミニマムプログラムを観察する

最初に極小プログラムで試してみましょう。GraalVMサイトの以下のような内容です。なお、今回のテストはOracle Cloud A1インスタンス上のUbuntu 22.04 (arm64)で行いました。

public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, World!");
  }
}

ネイティブイメージをビルドしてみると。。Javaクラスファイルに比べて非常に大きいのがわかります。(1000倍以上!)さらに、ビルドは非常に重い。4コアインスタンスでメモリを1GB近く消費して1分ほどかかりました。(たった4行のソースコードにです!)

ファイル サイズ
HelloWorld.class 427 bytes
helloworld(ネイティブ) 6781368 bytes (6MB!)

実行時のメモリ消費量はどうでしょうか?このページに書かれているtimeコマンドで最大利用メモリ(Maximum resident set size)を調べてみると、以下のようになりました。

ファイル Maximum resident set size (kbytes)
HelloWorld.class 36044 (36MB)
helloworld(ネイティブ) 1220 (1MB!)

利用メモリの劇的節約です!これは期待できそうです。

ミニマムSpring Boot Web + Data JPAで試す

次に本丸のSpring Boot Web + DBアプリケーションで試してみましょう。Spring BootのGithubから以下のサンプルを選びました。

https://github.com/spring-guides/gs-accessing-data-mysql/tree/main/complete

以下のコマンドでネイティブイメージをビルドします。

mvn -Pnative native:compile

コンパイルは多量のリソースを必要とします。4コアインスタンスで10分ほどで、利用メモリは8GBに達しました。

すぐには成功しませんでしたが、何点か調整すると、成功しました。

遭遇したエラーと対処方法は以下のようなものです。

エラー 対処方法
MySQLドライバがロードできない pom.xml依存関係にmysql-connector-jを追加。
実行時にクラス初期化エラー pom.xmlのparentをspring-boot-starter-parent v3.1.4に最新化。Reachability Metadataサポート追加

出来上がったネイティブイメージのファイルサイズは非常に大きいです。

ファイル サイズ
accessing-data-mysql-complete-0.0.1-SNAPSHOT.jar 44MB
accessing-data-mysql-complete(ネイティブ) 157MB

メモリ消費はどうでしょうか?サーバーが起動してから、最も単純なDB参照を伴うREST APIに1回レスポンスを返すまでの動作について、同様にtimeコマンドでメモリ消費量を比較してみると。。減りました!45%節約です!

ファイル Maximum resident set size (kbytes)
Jarで実行 320568 (321MB)
ネイティブで実行 175344 (175MB)

今後に期待

今回の実験はここまでですが、これは期待できると思います。ただし、今回調査していて感じたことですが、開発コードを正しく動かす道のりは簡単ではない場合がありそうです。JVMから事前コンパイルへの方式変更の実行環境へのインパクトは大きく、ソリューションの品質保証のためには非互換の開発モジュールをどうやって動かすか?などの難局を乗り切る知識がきっと必要になるでしょう。

今回も最後までお読みいただきありがとうございました。

Flect 社内における OR 技術の横展開に向けた取り組みの紹介

こんにちは.研究開発室の福井です.研究開発室においてオペレーションズ・リサーチ(OR)のビジネス活用について研究を行っております.本稿では,Flect 社内における OR の技術の横展開に向けた取り組みを紹介します.

続きを読む

ffmpeg.wasmをGitHub Pagesで動かすよ

こんにちは。研究開発室の岡田です。

Heroku 無料枠終了のお知らせの衝撃からだいぶ月日がたち、終了まで残り1か月強となりました。皆様におかれましては、有料プランへの移行準備あるいは、別サービスへの移行作業は進められておられますでしょうか。どうすべきか迷っておられる方は、識者の方々がいろいろと比較検討してくださっていますので、ご参考にされるといいと思います。(参考, 参考, 参考, 参考)

私も例にもれず、実験的なアプリはHerokuにデプロイするのが常であり、いろいろとお世話になっていました。慣れもあるかもしれませんが、Herokuの開発UXは非常に優れていると感じており、サーバ側で処理が必要となるようなアプリについては、引き続きHerokuを使ってもいいかなと考えています。一方で、サーバ側の処理がない、いわゆる静的なアプリについては、ソースコードと一緒にリポジトリで管理できるので、GitHub Pagesがお手軽でよさそうだなと考えています1

さて、私がHerokuにデプロイしていたアプリにはffmpeg.wasmを利用したものが幾つかあるのですが、実はこれをGitHub Pagesにデプロイする際には問題が発生します。ffmpeg.wasmを使用したことがある方にはおなじみの話だと思いますが、例のCOOP, COEP制限に引っかかってしまいブラウザで処理が行えなくなってしまうのです。今回は、これについて、簡単な説明と回避方法についてご紹介したいと思います。


  1. 最初からHerokuではなく、GitHub Pagesで動かしておけよ、という突込みはごもっともですが、開発環境を流用していた関係で、「まぁHerokuでいいか」ということになってました。そういう方、結構おられますよね?

続きを読む

Amazon Chime SDKでセンターフレームを作る

こんにちは。研究開発室の岡田です。

Amazon Chime SDK for Javascriptのバージョンが3.x系になって久しいですが、私がOSSで公開しているデモも漸くv3.xに対応させることができました。v2.x系からv3.x系への移行の手順は公式のドキュメントに記載されていますので、これから移行を考えておられる方はそちらを参考にされるとよいと思います。

今回はSDKの移行に伴い、デモに簡易版センターフレーム(Center Stage)を追加したので、その実装方法についてご紹介したいと思います。

つくったものはこんな感じのものです。 ezgif-3-c31fdaacf1

続きを読む