世界を動かす技術を、日本語で。

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

2025年6月4日原文(swift.org)

概要

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年の秋に導入された」と書いてあるから、サービスはそんなにレガシーじゃないんだろうね。

Hacker Newsで議論の続きを見る