AppleにおけるSwift: Javaからのパスワード監視サービスの移行

概要

AppleはPassword MonitoringサービスのバックエンドをJavaからSwiftに移行し、40%のパフォーマンス向上を実現。 Swiftの導入により、スケーラビリティ・セキュリティ・可用性が向上。 Swiftのプロトコル指向設計やasync/awaitが保守性・安全性を強化。 Kubernetes上で稼働し、メモリ使用量が大幅に削減。全体として、Swiftは高負荷環境での高効率・高信頼性を実証。

AppleにおけるSwift活用によるPassword Monitoringサービス刷新

Apple はクラウドサービス構築に Swift を本格採用し、優れた実績を獲得
2023年、 Password Monitoringサービス をSwiftで全面再実装、世界中のデバイスから日々数十億リクエストを処理
旧 Javaサービス 比で 40%のパフォーマンス向上、スケーラビリティ・セキュリティ・可用性も改善
2024年秋登場の Passwordsアプリ は、パスワード・パスキー・認証コードの管理、保存、自動入力、強力なパスワード生成・共有に対応
Password Monitoring は、漏洩リストとユーザー保存パスワードを定期照合し、漏洩検知時に警告
- サーバー側は Linuxベース、Appleが運用
- プライバシー重視設計 で、Appleがユーザーパスワードを知ることはない
- Private Set Intersection という暗号プロトコルを活用し、詳細はApple Platform Securityガイドに掲載

JavaからSwiftへの移行背景と課題

サービスの 高負荷・高速応答要件 に対し、Javaのメモリ管理方式が 拡張性・効率性目標 に合致しなくなった
JVMのチューニング や G1 GC による改善も限界、GC停止時間や負荷増加、複雑な調整が課題
インスタンスの起動・停止 が遅く、グローバル展開による負荷変動への迅速対応が困難
日々の 地域ごとのピーク・トラフ は最大50%変動、 動的スケーリング には高速ブートが不可欠
単純なハードウェア増強ではなく、 より効率的な言語 への移行が必要

Swift採用の決め手と開発体験

Appleは選択肢を検討し、 Swift が クラウドサービス要件 に最適と判断
Swiftの表現力豊かな構文 で学習コストが低く、パフォーマンスも十分
Vapor フレームワーク採用、Routing/Controller/Contentモジュールを活用
- 楕円曲線演算 等の独自要件に合わせ、カスタムパッケージも開発（監査・設定・エラー処理・ミドルウェア等）

Swiftの設計思想と利点

プロトコル指向設計 で、Javaの継承依存から脱却し、 モジュール性・再利用性 が向上
Optional型と安全なアンラップ でnullチェックを排除、 Null Pointer Exception リスク低減、可読性向上
async/await サポートにより、非同期処理が直感的かつ安全に記述可能、保守性・テスト容易性も向上

Swift移行後の成果

Swift化 でコード量が約 85%削減、表現力と可読性の高いコードベース実現
ロギング・Cassandraクライアント・暗号ライブラリ 等、Swiftエコシステムも活用
モジュール性・拡張性 重視設計で、将来的な機能追加・統合も容易
パフォーマンスベンチマーク で、99.9%のリクエストが1ms未満のレイテンシ、 40%スループット向上 を達成
メモリ使用量 はインスタンスあたり数百MBに抑制、旧Java実装（数十GB）から大幅削減
Kubernetes運用 で、サーバー容量の約50%を他ワークロードに転用可能に
運用安定性・信頼性 も向上、リソース効率・保守性・柔軟性を兼ね備えたアプリケーション基盤を実現

まとめ：Swift導入の意義

Swift は高負荷クラウド環境で 高速・堅牢・保守性重視 のアプリケーション開発に最適
メモリ・CPU効率、 安全性・信頼性、 設計の柔軟性 を兼ね備え、今後のサービス拡張にも対応可能
Appleの大規模サービス での実績が、Swiftのクラウド分野での実用性を裏付け

Hackerたちの意見

WWDCでXcode以外のエディタ（VSCodeやNeovimなど）向けのSwift開発に関する良いニュースが聞けることを期待してるよ。去年は「バックエンド開発者のいる場所に合わせる必要がある」って言って、sourcekit-lspや他の取り組みを改善する計画を発表したんだよね。

└

そうだね！今や公式のKotlin LSPもあるし…それがインスピレーションになるかもね。

└

個人的には、Appleは「Xをあるべき場所に合わせる」ってことに関しては全然実績がないと思う。Xcodeをクロスプラットフォームにすることもできるけど、絶対にやらないだろうね。

└

このプロジェクト、どんどん成熟してきてるね。https://github.com/swiftlang/vscode-swift それに、https://github.com/swiftlang/sourcekit-lsp はNeovimみたいなLSP対応エディタで使えるよ。

└

次のWWDCでAppleにお願いしたいのは、XcodeがM2を熱くしないようにしてほしいってこと。

└

これをずっと待ってた！ちなみに、純粋なSPMプロジェクトにはCLionのSwiftプラグインを使ってるけど、実際に結構良いよ。

└

15年間、主にiOSアプリを作ってきたけど、2016年以降はXcodeを使う必要がなくなった。FacebookやGoogleが完全に機能するVSCodeベースのエディタを持っていて、Linuxクラウドで分散ビルドができるから。すごくいいんだけど、このシステムのオープンソース版は知らないな。つまり、非MacハードウェアでiOSをビルドできるBazel/Buckとの統合ね。

└

最近、Swift SourceKit LSPとVSCodeが結構良くなってると思う。Swift/CMakeプロジェクトでCMakeと一緒に動かすのができたんだけど、唯一の面倒だったのはCMakeの設定をちゃんとすることだった。他はVSCodeの拡張機能マネージャーでそのまま動いたよ。

前のJavaサービスと比べて、更新されたバックエンドはパフォーマンスが40%向上し、スケーラビリティ、セキュリティ、可用性も改善された。こういうリライトではいつもそうだけど、改善が言語の選択から来たのか、古いレガシーコードを更新してバグやボトルネックを修正したからなのかが大きな疑問だね。

└

普通なら君のコメントに同意するけど… メモリ使用量が90%減少したってことを考えると（おそらくJavaのGCとSwiftのAOTメモリ管理の違いから）、実際には言語の違いから得られた利点の方が大きいように思えるね。

└

RustやGoが達成できたことを想像してみて。

└

投稿には、ユーザー向けアプリが「2024年の秋に導入された」と書いてあるから、サービスはそんなにレガシーじゃないんだろうね。

└

こういうコメントを見るのが大好き。JVM上では、Springみたいなクソみたいなものを使って、全てを過剰設計しちゃうんだよね。1つの文字列をメモリに保持するのに、20種類の型やインターフェース、オブジェクトが必要とか。JVMもメモリを食うけど、まあまあ見た目は良くできるけど、他の技術に比べたらまだまだ劣るよね。

└

僕の意見としては、Javaがまだ値型を持っていないのに対して、Swiftは持っているってのが、効率性の向上に大きな理由だと思う。

└

そうだね！パフォーマンス向上の原因を深く分析してたら、もっと情報が得られたと思う。でも、AppleはAppleだから、内部システムの詳細を公開することはないだろうし、結局は曖昧な発言しか得られないんじゃないかな。

└

同意。ここからほとんどの利点が生まれることが多いよね。v1を参考にしながらv2のソフトウェアを書くことができるから。

└

メモリ消費が90%削減されたことで、ほとんどすべてのパフォーマンス改善がそこから来たんじゃないかな。実際、ハードウェアの利用率が50%しか下がらなかったのはちょっと驚きだよ。クラウドアプリケーションのメモリ消費が減ったことが、IBMがしばらくSwiftに興味を持っていた主な理由だったらしい。ほとんどのクラウドアプリケーションは大半の時間アイドル状態にあるから、単一の物理ホストでマルチプレクスできるクライアントの数は、CPUのスループットではなくメモリ消費によって制限されるんだ。JavaはJITとGCがあるから、メモリ消費がひどいよね。

└

まあ、ビジネスにお金を出してもらって、同じ言語で業務用ソフトウェアを作り直すのと、別の言語でやるのを試してみるのもいいかもしれないね。結果が出ると思うよ。実際の数字が出てくるはずだけど、未来に同じ「質問」をする人たちは、その数字を無視するだろうね。「ただ書き直せば良くなる」って言ってる人たちが、思ってるほど正しいなら、JWZの「注意欠陥ティーンエイジャーのカスケード」現象が大きな謎だよ。このシナリオでは、同じソフトウェアが何度も書き直されるけど、速くならないし、深刻なバグも直らないんだよね。

とても興味深いね。他の技術についてもう少し詳しく説明してほしかったな。JavaサービスはSpring（Boot）で動いてたの？他にどんな技術が考慮されたのかな？Goもその中に入ってると思うけど。Goの型システムが単純すぎたってだけなのか、それとも他にどんな要因があったのかな？

└

SwiftはAppleの自社言語だからね。彼らにはあらゆるレベルの専門家が揃ってる。競合技術の公正な技術評価のために長ったらしいレポートや記事を書くのは、完全に無駄な時間だし、もし答えがSwiftだったとしても誰も信じないだろうね。 > Goもその中に含まれてたと思う。... Goを評価する理由は全く見当たらないね。

└

Appleはservicetalk[1]（nettyの上に構築されたJavaのネットワーキングフレームワーク）を維持してるから、これが使われてたJVMフレームワークの一つなんじゃないかな。 [1] https://github.com/apple/servicetalk

なんで大企業って、専門家を雇えるリソースがあるのに、RustやElixir/Phoenixみたいな技術に詳しい人を雇わないんだろうって、ずっと疑問に思ってた。JavaやC#みたいな一般的な開発者を雇いたいってのは分かるけど、長期的な計画や実行戦略があるなら、もっとリターンが大きい技術を選んでもいいんじゃない？ITT: Swiftを選んだ理由は分かるよ、Appleの自社技術だからね。全然悪くない、いい記事だね。

└

理由はいくつもあるけど、典型的な企業が雇って利益を得るほどのRustの専門家が世界に足りてないんだよね。Elixir/PhoenixはRustほどの大きな改善にはならないし、微妙な改善に過ぎない。企業はそんなの気にしないよ。

└

JavaやC#があまりにも一般化されてるから、あんまり人にお金を払わなくて済むんだよね。それに、中小企業や小規模SaaSの世界では、長期的なプロダクト管理よりも短期的なバランスシートが重要なんだと思う。開発者以外は誰も気にしてないんじゃないかな。

└

Elixirのポジションはあるよ、例えば https://jobs.apple.com/en-us/details/200562288/senior-softwa...

私たちのJavaサービスが直面した課題の一つは、JVMのオーバーヘッドのせいで、インスタンスを迅速にプロビジョニングしたり、廃止したりできないことでした。... これを効率的に管理するために、需要が低いときはスケールダウンし、需要がピークに達したときには地域ごとにスケールアップすることを目指しています。でも、これは完全に非同期なサービスで、非常に緩いレイテンシ要件があるように見える: > 定期的に、パスワードモニタリングがユーザーのパスワードを、漏洩が確認されたパスワードのリストと照合します。なんでバックエンドの裁量でチェックしないの？

└

なぜバックエンドの裁量でチェックを実行しないの？おそらく、コンピュータが起きていてオンラインのときにやる必要があるのと、パスワードアプリが最近更新されていなければ起動時にデータをリフレッシュするからだと思う。

└

「なぜバックエンドの裁量でチェックを実行しないの？」他の側が計算が終わったときに聞いていないかもしれないし、プライバシーの観点から計算結果をキャッシュしたくないからだよ。イベントの流れはこうだよ：1. 電話がバックエンドにリクエストを送信する。2. 電話がバックエンドからのレスポンスを待つ。1と2の間のギャップは長くできない。待っている間、電話はずっとバッテリーを消耗しているから、デバイスが待つことができる合理的な時間には限界があるんだ。プライバシーに敏感でないアーキテクチャなら、こうできるかも：1. 電話がバックエンドにリクエストを送信する。後でレスポンスを確認するためのトークンを取得する。2. 電話が後でトークンを使ってレスポンスを確認する。でも、それにはバックエンドがレスポンスを保持しておく必要があるから、プライバシーに敏感なアプリケーションでは望ましくないよね！

この記事にはバイアスがあるかもしれないけど、クラウドのコンピュートやメモリ使用量にお金を払ってる会社にとっては、リソース使用の改善は無視できないよね。サーバーサイドのSwiftを調べてみるつもり。Linuxでの開発に適した非Xcodeツールを見つけるのにはちょっと手間がかかりそう。JetbrainsのツールがVSCodeより好きなんだけど、もし何かヒントがあれば教えてほしいな。

└

Swift自体に特別な魔法があるとは思わないけど、JVMの大きなランタイムなしで動かすことやメモリ管理の利点が違いを生んでるんじゃないかな。Goも改善をもたらすだろうし（JVM言語からのメンタルシフトも楽だと思う）、Rustもそのモデルに慣れればもっと大きな改善が得られるよ。Swiftはオブジェクト指向の利点があるけど（それが利点だと思うなら）、10年前にはマイクロサービスの流れでJava/Springアプリがクラウドやマイクロサービスモデルの迅速な起動・停止にあまり適してないんじゃないかと思ってた。

└

残念ながら、JetbrainsはもうAppCodeを販売していないし、CLion用のSwiftプラグインもサポートしていないんだよね。プラグインをオープンソースにしてくれたらいいのに。CLionはXcodeよりもずっと優れてるから。今のところは、Xcode（Mac）かVSCode（どこでも）を使うしかないけど、最近はVaporを使ったサーバーサイドSwiftがめっちゃ好きになってきた。Swift自体は開発するのにすごくいい言語だよね。

AppleがLinux上のSwiftアプリケーションで生産監視、可観測性、パフォーマンスプロファイリングに何を使ってるのか気になるな。私の経験では、これがSwiftサーバーエコシステムで欠けている重要な要素の一つだと思う。jemallocにリンクして、Googleのperftoolsを使ってヒープやCPUプロファイルを取得することはできるけど、Swiftのメソッドマングリングや積極的なインライン化があるから、うまく活用するのは難しいんだよね。

Javaアプリケーションの詳細なプロファイリング分析がないと、この全体が広告的なコンテンツに見えてしまうのは仕方ないよね。Javaのどこにボトルネックがあったのか、Swiftと比べてどの部分が大きな改善点だったのかが分からない。サービスの範囲がすごくシンプルに見えるから、前のバージョンに何か根本的な問題があったのかもしれない。トラフィックの不規則なバッチ処理にうまくスケールしないコードとか、最新のネイティブIO構造を活用していないカスタム暗号化コードとかね。Javaを擁護するつもりは全くないけど、Javaってしばしば80年代のボルボみたいなもので、信頼性は抜群だけど、全速力で運転するよりもその変な音を理解するのに時間を費やすことが多いんだよね。

└

Javaアプリケーションの詳細なプロファイリング分析がないと、この全体が広告的なコンテンツに見えてしまうのは仕方ないよね。Appleが書いたものがあなたを満足させるとは思えない。TFAは、彼らがまずJavaのバージョンをJavaのGCの下でできる限り最適化したこと、再構築が必要だと分かった時にいくつかの言語（Swiftだけじゃない）を評価したこと、開発とデプロイメントの過程で「パフォーマンスをベンチマークした」こと、そしてビフォー・アフターのベンチマークを共有したことを明確にしているよ。

AppleがサーバーサイドでSwiftを使ってるって聞いて、サーバーのSwiftに対する見方が変わったよ。もう一度じっくり見てみるつもり。成熟してきて、他の選択肢としても十分使えるようになってきたのは嬉しいね。

今言っちゃうけど、バックエンドでのSwiftはApple以外には意味がないと思う。バックエンドサービス言語として普及させようとするのは、Xcodeをクロスプラットフォームに移植して、非Appleの開発者をVSCodeやJetBrainsのIDE、Visual Studioよりも使わせようとするのと同じくらい無駄だよ。市場にすでにある選択肢が多すぎて、既存のツールはAppleが提供できるものよりも機能や能力が遥かに優れてるからね。面白いのは、AppleにはC#やJava、Go、Rustと競争するためのリソースを投入するお金があるのに、彼らのコアビジネスから遠すぎるからやらないってこと。Swiftで書かれたバックエンドサービスは、クラウド上のMacで動くことはないし、iPhoneやiPadだけにサービスを提供するわけでもないから、Appleのリーダーシップが後回しにするのは明らかだよ。もし普及することがあれば、それはオープンソースコミュニティが解決策を提供するからだと思う。Appleじゃなくてね。それでも、ほんの小さなニッチになるだろうね。実際、このプロジェクトはVaporというオープンソースのSwiftプロジェクトによって実現されてるけど、チームが選んだのはVaporが彼らが求めていた成熟度に達したからだと思う。Appleが自分たちでSwiftでウェブフレームワークを作ったわけじゃないし、MicrosoftがC#やASP.NETでやってるみたいにね。これらのことから、バックエンドでのSwiftに対してますます懐疑的になってるよ。Appleは基本的なこと以外に、バックエンド分野でSwiftを優位にするための特別なことは何もしないだろうし、Linuxに移植するくらいだろうね。でも、他の人が作ったオープンソースのものは利用するだろうけど。

└

Appleは確かにSwiftで書かれたウェブフレームワークを持ってるよ。なんで公開されてないのかは知らないけど（少なくともまだね）。でも、いくつかの公共サービスを支えてることは知ってるよ。

└

Hacker NewsでのSwiftに対する人々の反応がすごく気になる。5年前にはもっと聞いた気がする。みんなGoが好きで、Rustもクールだし（私もそれを学んだ）、Python、C#、Javaは残りそうだね。一般的なプログラミング言語として聞いてるんだけど、バックエンドだけじゃなくて。

ハクソク