Webプロジェクトで使うフレームワーク技術まとめ

以下は、普段の業務や自己学習の中で触れて使ってみた技術の一部を、記録として整理したものです。

このリストを書き始めたきっかけは単純です。Java Web のエコシステムはあまりにも広く、モノリシックなプロジェクトから始まり、マイクロサービス、コンテナ化、監視・アラートまで、各レイヤーに複数の選択肢があります。普段は断片的に触れるだけなので、しばらく経つと名前しか覚えておらず、位置づけを思い出せなくなります。そこで一箇所にまとめて、それぞれについて「何であるか、どんな問題を解決するか」を明記しておくことにしました。今後の技術選定の際には、改めて検索し直すのではなく、このページを見返せば済みます。リストはおおよそ「開発フレームワーク → データ層 → マイクロサービスガバナンス → インフラ → ビッグデータ・ツール」の順に並べています。

SpringBoot、Spring-cloud、Spring-cloud-alibaba、Spring ファミリー。SpringBoot は自動構成（Auto Configuration）とスターター依存によって設定量を最小限に抑えており、現在の Java プロジェクトのデフォルトの出発点です。Spring Cloud はその上にサービス登録、設定管理、ゲートウェイなどのマイクロサービス機能を提供します。Spring Cloud Alibaba は Nacos、Sentinel、Seata といった中国発エコシステムのコンポーネントを同じ抽象化レイヤーに統合しています。

MyBatis-Plus（楽観ロック、自動ページネーション、コードジェネレーター。service、mapper、entity、controller を生成でき、生成テンプレートもカスタマイズ可能）。MyBatis の上に汎用 CRUD を補完しており、単一テーブルの操作ではほぼ SQL を書く必要がありません。コードジェネレーターとカスタムテンプレートを組み合わせれば、新しいテーブルの CRUD を数分で組み立てられます。

JOOQ：Java の ORM フレームワーク。発想は MyBatis とは逆で、Java の DSL を使って型安全に SQL を組み立てます。フィールド名の間違いをコンパイル時に発見できるため、SQL ロジックが複雑で、かつ強い型保証が欲しい場面に適しています。

Uid-generator：Baidu 製の UID ジェネレーター（分散スノーフレークアルゴリズムによるグローバル一意識別子、Long 型 UID）。シャーディング後はデータベースの自動採番主キーが使えなくなります。スノーフレークアルゴリズムは「タイムスタンプ + マシン ID + シーケンス番号」を組み合わせて単調増加傾向の Long 型 ID を生成し、グローバル一意性とインデックスへの優しさを両立します。

Xxl-job：分散タスクスケジューリングセンター。単一マシンでの定期タスクにある二つの古典的な問題——マシンが落ちるとタスクが失われる、複数インスタンスにデプロイすると重複実行される——を解決します。スケジューリングセンターと実行器を分離し、管理画面、失敗時のリトライ、シャーディング実行を標準搭載しています。

Apache-Shiro、Spring-Security：ログイン・セキュリティフレームワーク。どちらも認証と認可をカバーします。Shiro は軽量で習得が容易、Spring Security は機能がより充実し Spring エコシステムとの統合も深いですが、設定の学習曲線は急です。

Druid ali、HikariCP：よく使われるデータベースコネクションプール。コネクションプールの意義は、データベース接続を再利用して頻繁なハンドシェイクを避けることにあります。Druid は SQL 監視とインジェクション対策の統計画面を備え、HikariCP は性能に定評があり SpringBoot のデフォルトです。

Bcrypt：データベースのユーザーパスワード暗号化方式で、パスワードの安全を保証します。低速ハッシュであり、毎回ソルトが異なる結果を生成するため、たとえデータベースが流出してもレインボーテーブルで一括逆算するのは困難です。MD5/SHA でハッシュをそのまま保存するよりはるかに堅牢です。

JWT：一時トークン生成の戦略・仕様。ユーザー情報に署名を付けてトークン自体に埋め込むため、サーバー側でセッションを保持する必要がなく、複数インスタンスへの水平スケールと自然に相性が良いです。代償として、発行後に能動的に無効化できないため、短い有効期限やブラックリストで補う必要があります。

Undertow、Tomcat、Jboss、Weblogic：Servlet コンテナ。Tomcat が最も汎用的です。Undertow は NIO ベースでメモリ使用量が小さく、SpringBoot の組み込みコンテナの置き換えによく使われます。JBoss、Weblogic はより重量級の商用アプリケーションサーバーです。

Eolinker、Swagger、Knife4j、Yapi：オンライン API ドキュメント・自動化テストツール。核心的な価値は、ドキュメントをコードのアノテーションから自動生成し、コードの更新に追従させることです。「ドキュメントと API が一致しない」というフロントエンド・バックエンド間の典型的な揉め事を回避できます。Knife4j は Swagger の中国製強化 UI です。

MySQL 8.0、PostgreSQL：RDS リレーショナルデータベース。ビジネスデータの主たる保存先です。MySQL はエコシステムと資料が最も豊富、PostgreSQL は機能がより完全で、JSON や GIS のような用途で優れています。

Sqlite：組み込みデータベース。データベース全体が一つのファイルで、独立したプロセスを必要としないため、クライアントのローカルストレージや小さなツールに適しています。

Redis、MongoDB：NoSQL 非リレーショナルデータベース。Redis はメモリベースで、キャッシュ、分散ロック、カウンターによく使われます。MongoDB はドキュメント型データベースで、スキーマが柔軟なため構造が変わりやすいデータに向いています。

Dobbo、Feign：リモートメソッド呼び出し。どちらも、サービス間の呼び出しをローカルメソッドのように書けるようにするものです。Dubbo は独自プロトコル + 長時間接続で性能に優れ、Feign は HTTP ベースの宣言的インターフェースで、Spring Cloud 体系との組み合わせがより自然です。

Sentinel、Hystrix：レートリミット、フォールバック。マイクロサービスの自己防衛手段です。上流からのトラフィックが処理能力を超えたらまずレートリミットし、依存する下流サービスが落ちたら即座に失敗させてフォールバックロジックに切り替えます。スレッドが枯渇して障害が呼び出しチェーンに沿って波及する——いわゆるカスケード障害（雪崩）を防ぎます。Hystrix はすでに新機能開発を停止しており、新規プロジェクトでは通常 Sentinel を選びます。

Skywalking：分散トレーシング（Huawei が開発し Apache に寄贈）。Java Agent によるバイトコード拡張で計装するため、ビジネスコードに侵入することなく、一つのリクエストが複数のサービスをまたぐ完全な呼び出しチェーンを可視化できます。「どの段階が遅いのか」を調査する際に非常に直観的です。

Zookeeper、Eureka、Consul、Nacos、Etcd：サービスレジストリ・設定センター。レジストリは「サービスインスタンスのアドレスが動的に変わる中で、呼び出し側がどうやってそれを見つけるか」という問題を、設定センターは「設定変更のたびに再起動が必要」という問題を解決します。Nacos は両者を一つに統合しており、Spring Cloud Alibaba 体系のデフォルトです。Etcd は Kubernetes の基盤ストレージでもあります。

Seata：Alibaba の分散トランザクションソリューション。一つの業務操作が複数のデータベースや複数のサービスをまたぐ場合、ローカルトランザクションでは全体の整合性を保証できません。Seata の AT モードはデータソースをプロキシしてロールバックログを自動記録するため、ビジネスコードへの侵入が非常に小さいです。

ELK：分散ログ収集、データ集約、分散検索エンジン。つまり Elasticsearch + Logstash + Kibana の組み合わせです。各ノードのログを収集して集中保存し、全文検索と可視化画面で照会します。サービスが増えると、集中型ログなしでは問題調査はほぼ不可能になります。

Micrometer、Prometheus、Grafana：サービスヘルス監視、データ監視、I/O 監視など。Micrometer がアプリケーション側でメトリクスを公開し、Prometheus が定期的にプルして時系列データとして保存し、Grafana がグラフ描画とアラートパネルを担当します。この三つは現在最も一般的な監視の組み合わせです。

Kafka、RabbitMQ、RocketMQ：よく使われるメッセージキュー。ピークカット、疎結合化、非同期化に使います。プロデューサーは投げるだけ、コンシューマーは自分のペースで処理し、トラフィックの洪水はまずキューに落として徐々に消化します。Kafka はスループットが最も高くログ・ストリーム処理向き、RabbitMQ はルーティングが柔軟、RocketMQ はトランザクションメッセージや遅延メッセージの機能がより充実しています。

Nginx、apache-http-service、Traefik：HTTP サーバー。静的リソースのホスティングに加えて、リバースプロキシと L7 ロードバランシングを担うことが多いです。Traefik はコンテナを自動検出してルーティングルールを更新できるため、コンテナ環境との相性が良いです。

Ali-OSS、HUAWEI-OBS：サードパーティの静的リソースストレージ。画像や添付ファイルのようなファイルは、アプリケーションサーバーのディスクではなくオブジェクトストレージに置くことで、運用の手間が減り CDN による高速化とも組み合わせやすくなります。

Ali-NAS：内部ネットワーク共有ファイルストレージのマウント、内部ネットワーク共有ディスク。複数のマシンが同じファイルを読み書きする必要があるとき NAS をマウントすれば、自前で NFS を構築するよりも運用作業がかなり少なくて済みます。

Ali-SLB：L4・L7 ロードバランサー。トラフィック入口の最初の一層で、L4 は TCP を転送し、L7 はドメインやパスで振り分けできます。通常はその後段に Nginx とアプリケーションが続きます。

Findbugs、Sonarqube：静的コード解析。コードを実行せずに、NullPointerException の潜在リスクやリソースの閉じ忘れといった問題を検出できます。SonarQube は CI に組み込んで、品質ゲートで基準未達のコミットをブロックすることもできます。

PDMan：中国の開発者によるデータベース可視化ツール。ER 図の作成、テーブル構造のバージョン管理、CREATE TABLE 用 SQL のエクスポートに使います。チーム協業では口頭でテーブル構造を取り決めるより、はるかに確実です。

Docker、Containerd、CRI-O：代表的なコンテナランタイム。コンテナはアプリケーションと依存関係を一つのイメージにまとめるため、「自分のマシンでは動くのに」という問題はほぼ消えます。Containerd、CRI-O はより低レベルのランタイムで、Kubernetes は CRI インターフェースを通じて直接それらと連携します。

Docker-Compose：コンテナオーケストレーションツール。一つの YAML ファイルで複数コンテナのイメージ、ポート、依存関係を記述し、コマンド一つでローカル環境一式を立ち上げられます。開発時の結合テストにとても便利です。

Kubernetes：コンテナオーケストレーション、運用、リソース管理、リソーススケジューリングのワンストップ管理。核心となる考え方は宣言的アプローチです。望ましい状態を記述すれば、スケジューリング、スケールイン・アウト、障害からの自己修復を Kubernetes が担い、実際の状態を望ましい状態へと収束させ続けます。現在、本番環境のコンテナオーケストレーションにおける事実上の標準です。

Istio：よく使われる Service Mesh フレームワーク。多言語協調でのバックエンド開発、トラフィック制御、フォールバック、サーキットブレーカーに対応します。Service Mesh はレートリミット、サーキットブレーカー、カナリアリリースといったガバナンスロジックをビジネスコードから Sidecar プロキシに下ろすため、異なる言語で書かれたサービスでも同じガバナンス機能を共有できます。

Helm：K8S アプリケーションリソース管理ミドルウェア。Kubernetes のパッケージマネージャーに相当し、大量の YAML を Chart としてテンプレート化して、コマンド一つでインストール、アップグレード、ロールバックを完了できます。

Ali-EsayExcel：Alibaba がオープンソース化した高効率 Excel 処理 jar パッケージ。POI が大きなファイルでメモリ溢れを起こしやすい問題に対してストリーミング読み書きの最適化を施しており、数十万行のインポート・エクスポートでも安定しています。

Netty：よく使われる Java NIO ネットワークプログラミングパッケージ。NIO の煩雑な Selector、Buffer の細部をイベント駆動の Pipeline モデルに包み込んでおり、多くの RPC フレームワークやミドルウェアのネットワーク層の土台になっています。

Disruptor：高性能インメモリキュー（英国の外国為替取引会社 LMAX が開発）。リングバッファでメモリを事前確保し、ロック競合と False Sharing を回避することで、単一マシンでのスレッド間メッセージ受け渡しのレイテンシを極めて低く抑えられます。

Caffeine：JVM ローカル高性能キャッシュコンポーネント。内部で Disruptor を利用して開発されています。プロセス内キャッシュなのでアクセスにネットワークを経由せず、Redis と組み合わせて二段キャッシュを構成するのが定番です。ローカルでホットスポットを受け止め、Redis で共有を保証します。

Jenkins：CI/CD ミドルウェア。自動デプロイ、パイプライン生産。コード取得、コンパイル、テスト、イメージビルド、デプロイをパイプラインとしてつなぎ、コミット後に自動で一連の処理を実行することで、手作業デプロイのミスの余地を減らします。

Apahce-Hdoop：分散ビッグデータストレージとデータ処理。Hadoop の HDFS は大きなファイルをブロックに分割し冗長化して複数マシンに保存し、MapReduce はデータのあるノードの近くで計算を行います。ビッグデータ体系の古参の土台です。

Apahce-Flink：ストリーム処理フレームワークで、ビッグデータにおける準リアルタイム計算に適しています。計算をデータストリーム側に押し下げ、イベントが到着した時点で処理します。状態管理と Exactly-Once セマンティクスをサポートしており、リアルタイムレポートやリアルタイム不正検知でよく使われます。

MyCat2、Apache-Shardingsphere：シャーディング（分庫分表）ミドルウェア。単一テーブルのデータ量がクエリに耐えられないほど増えたときに水平分割を行います。ミドルウェアが SQL を解析し、対象のシャードへルーティングして結果をマージするため、アプリケーションはできるだけ意識せずに済みます。

TiDB、KunlunBase：NewSQL 分散リレーショナルデータベース。同じ問題を別の発想で解決します。データベース自体を分散化し、MySQL プロトコルと互換性を持たせることで、スケールアウトの際にアプリケーション側でシャーディングルールを改修する必要がなくなります。

Arthas：Alibaba がオープンソース化した JVM 診断ツール。フレームグラフ生成、デッドロック診断など。再起動もコード変更もせずに本番の JVM にアタッチして、メソッドの所要時間の確認、クラスの逆コンパイル、呼び出しのトレースができます。本番の難問を調査する際の救命ツールです。

Kettle、DataX、Canal：オープンソースの ETL ツール。データ移行、データクレンジング。前の二つはバッチでの抽出・変換を行います。Canal は少し特殊で、MySQL のスレーブに擬態して binlog を解析することでリアルタイムの増分データを取得でき、キャッシュ同期や異種データ同期によく使われます。

Jmeter：よく使われる API テスト・負荷テストツール。リリース前に一通り負荷をかけて、API のスループット上限とレスポンスタイム分布を把握しておけば、レートリミットの閾値に根拠を持たせられます。勘で決めるのではなく。

Ansible：複数サーバーの運用ツール。SSH ベースで対象マシンに Agent をインストールする必要がなく、YAML で望ましい状態を記述して一括実行します。数十台のマシンの設定を一つ変更するのに、一台ずつログインする必要はありません。

ハマりどころと注意点

• リストは技術選定そのものではありません。同じレイヤーのコンポーネント（例えば Sentinel と Hystrix、Eureka と Nacos）はどちらか一つを選べば十分で、リストにあるものを全部プロジェクトに詰め込んでも保守コストが増えるだけです。
• まずは体系に沿って選ぶこと。Spring Cloud Alibaba を使うなら、レジストリ、レートリミット、分散トランザクションはそのまま Nacos、Sentinel、Seata を選ぶのが自然です。異なる体系のコンポーネントを混在させると、互換性の問題を自分で背負うことになります。
• コンポーネントのメンテナンス状況に注意。エコシステムの移り変わりは速く、Hystrix のようにメンテナンスモードに入ったプロジェクトは新規システムではできるだけ避け、コミュニティが活発に開発を続けている代替品を選びましょう。
• 分散コンポーネントにはどれも運用コストがあります。Kafka、Elasticsearch、Kubernetes はそれぞれ専任者が研究する価値のあるもので、小さなチームは導入前に誰が保守するのかをよく考えるべきです。

まとめ

このリストは、Java Web プロジェクトにおける開発フレームワーク、データストレージ、マイクロサービスガバナンスから、コンテナ化、ビッグデータまでのおおよその全体像をカバーしています。記録する目的はすべてを使うことではなく、具体的な問題に出会ったときに、どんな既存のソリューションがあり、それぞれの位置づけが何かを知っていることです。エコシステムは変化し続けているので、このページも実際の利用に合わせて追記・修正していきます。