System.out.println("Java学習中");

【Java / Spring Boot】UI/UXの視点を活かしたバックエンド開発の学習ポートフォリオ

【AWSデプロイ奮闘記:第4回】いざEC2へ潜入!無料枠サーバーを強化するスワップメモリ作成とJavaエンジン搬入

Adobe Fireflyで作成

🗺️ はじめに

前回の記事では、

AWSアカウントの「ルートユーザー」を安全に封印し、自分だけのまっさらな仮想サーバー(EC2)をクラウド大陸に建設する手順

について解説しました。

📝前回の記事はこちら👇

blog.kenichikamoi.com

今回はいよいよ、前回ダウンロードした「鍵ファイル(.pem)」を使って、サーバーの内部へ潜入(リモート接続)していきます。

これまではAWSの管理画面「更地」を作ってきましたが、ここから先は「黒い画面(Linuxターミナル)」での作業がメインになります。

今回のミッションは、

建ったばかりのサーバー内部で行う「本格的な内装工事」

です。

無料枠のサーバー(t3.microなど)メモリが1GBしかありません。

そのままでは、大食漢のJavaアプリを動かそうとした瞬間に

作業机が狭すぎて(メモリ不足で)サーバーごとフリーズしてしまう

という、初心者が陥る罠が待ち受けています。

そこで今回は、以下の2つの工事を行ってサーバーを強靭に鍛え上げます。

🔹作業机を広げる(スワップメモリの作成):ハードディスクの一部をメモリ代わりに使って、無料枠サーバーでもJavaがサクサク動くように補強します。

🔹エンジンの搬入(Java&MySQLのインストール):アプリを動かすための土台となるソフトウェアをインストールします。
黒い画面(Linuxターミナル)のコマンドなんて難しそう…

と不安に思うかもしれませんが、コピペで安全に進めていけば全く問題ありません。

それでは、サーバー内部へ潜入しましょう。


💻 リモート接続(SSH接続)

前回ダウンロードした「鍵ファイル(.pem)」を使って、手元のWindows PCからAWS上のサーバーリモート接続(SSH接続)してみましょう。

SSH接続とは、

インターネット上に暗号化された安全な地下通路を作り、そこを通って遠隔操作する技術

のことです。

ステップ1:サーバーの「住所(IPアドレス)」を確認する

まずは、AWSのEC2ダッシュボード画面を開き、作成したインスタンス(task-app-web)をクリックします。

画面下部の「詳細」タブの中にある

パブリック IPv4 アドレス(例:198.51.100.23 のような数字の羅列)

をコピーしてメモしておきます。

これが、

あなたのサーバーのインターネット上の住所

になります。

ステップ2:黒い画面(PowerShell)を起動する

Windowsの左下にあるWindowsボタンをクリックし、検索窓に PowerShell と入力して、「Windows PowerShell」を起動します。

※コマンドプロンプトでも大丈夫ですが、今回はPowerShellを例に進めます。

ステップ3:鍵がある場所(フォルダ)へ移動する

PowerShellが開くと、文字を入力できる状態になります。

ここで、前回ダウンロードした鍵ファイル(例:task-app-key.pem)が保存されている場所へ「移動」する必要があります。

もし「ダウンロード」フォルダに保存した場合は、以下のコマンドを入力してEnterキーを押してください。

cd Downloads

「cd(チェンジ・ディレクトリ)」は、フォルダを移動するコマンドです。
もしデスクトップに保存した場合cd Desktop と入力してください。

ステップ4:サーバーへ接続するコマンドを入力

鍵ファイルがある場所まで移動できたら、いよいよサーバーへ接続するコマンドを打ち込みます。

以下のコマンドの<IPアドレス>(@以降)の部分を、ステップ1でコピーした数字に置き換えて入力し、Enterを押してください。

ssh -i task-app-key.pem ec2-user@

ec2-user というのは、Amazon LinuxというOSにもともと用意されている「管理者(あなた)の初期のユーザー名」です。

ステップ5:門番の質問に「yes」と答える

初めてこのサーバーに接続しようとすると、英語で次のような警告メッセージが出ます。

Are you sure you want to continue connecting (yes/no/[fingerprint])?
(このサーバーに初めて接続するけど、本当に進めてもいいですか?)

これは

初回接続時の「門番の確認」

のようなものです。

yes と入力してEnterを押してください。

🎉 潜入成功

画面の左側の文字が、以下のような表示に変われば成功です。

[ec2-user@ip-xxx-xxx-xxx-xxx ~]$

インターネットの地下通路を通って、AWS上の自分だけの城(サーバー)の内部に潜入できました。

ここからは、

入力するすべてのコマンドが、あなたのPCではなく「AWS上のサーバー」の中で実行される

ようになります。


🛠️ 作業机を広げる(スワップメモリの作成)

無事に接続できると、黒い画面に

「Amazon Linux」の鳥のロゴ(アスキーアート)

が表示されたはずです。

「ついに本物のLinuxサーバーに入った!」

という実感が湧いてきますね。

ここからは、いよいよコマンドを叩いていく本格的なインフラ構築フェーズです。

まずは、これから動かすJavaアプリ無料で、かつ安定して稼働させるための

補強工事(スワップメモリの作成)

を行います。

🤔 なぜスワップメモリ(仮想メモリ)が必要なのか?

現在稼働している無料の t3.micro サーバーは、物理的なメモリ(作業机の広さ)「1GB」しかありません。

しかし、これから動かすJava(Spring Boot)のアプリケーションは非常に多くのメモリを消費する大食漢です。

このままだと

作業机が狭すぎて(メモリ不足で)サーバーごと強制終了してしまう

という危険があります。

そこで、余っているハードディスクの一部を

仮想的なメモリ(2GB分の補助引き出し)

として使わせる設定を行い、システムを強固にします。

以下のコマンドを「1行ずつ」コピー&ペーストして、Enterキーを押して実行していってください。

※黒い画面へのペーストは、右クリックでできることが多いです。

🚀 スワップメモリ作成のコマンド手順

1. 2GBの空のファイル(スワップ領域)を作成する**

sudo dd if=/dev/zero of=/swapfile bs=128M count=16

※このコマンドは完了まで数秒〜十数秒かかります。次の入力待ちになるまで少しお待ちください。

2. セキュリティのため、管理者だけが読み書きできるように権限を変更する

sudo chmod 600 /swapfile

3. 作成したファイルを「スワップメモリ」としてフォーマットする

sudo mkswap /swapfile

4. スワップメモリを実際に有効化する

sudo swapon /swapfile

5. サーバー再起動時にも設定が消えないように、システム設定に追記する

sudo sh -c 'echo "/swapfile swap swap defaults 0 0" >> /etc/fstab'

🧪 補強工事の品質確認(テスト)

すべてのコマンドが完了したら、本当に作業机が広くなったのか、ステータス確認を行います。

実際の運用保守の現場でも、トラブルシューティングの第一手としてよく使われるコマンドです。

以下のコマンドを実行してみてください。

free -h

📏 free -h の意味

🔹free: 「今のメモリの空き容量と使っている容量を教えて!」という命令です。

🔹-h: 「Human-readable(人間にとって読みやすい形式で)」の頭文字です。これがないと「2147479552 バイト」のように細かすぎる数字を出してくるため、人間がパッと見て分かる「G(ギガ)」や「M(メガ)」の単位に翻訳してくれるオプションです。

✅ 確認ポイント

実行結果の中に Swap: という行が現れ、その横の total の部分に 2.0G (またはそれに近い数字)が表示されていれば、補強工事は成功しています。

🔸Mem の行: サーバー本来の作業机の広さ(約1GB)

🔸Swap の行: 今回新しくDIYで作った、机の横の「補助引き出し(2GB)」の広さ

これで、どんなにタスク管理アプリメモリを要求しても絶対に落ちない、強靭なインフラ基盤が完成しました。


📦 サーバーに「Javaエンジン」を搬入する

スワップメモリで作業机を広げたら、次はいよいよ

アプリを動かすためのエンジン(Java)

サーバーにインストールします。

今のサーバー

地盤を補強しただけの空っぽの更地

です。

ここでJavaアプリを動かすためには、

実行環境(JRE/JDK)

という専用の設備を搬入する必要があります。

AWSが提供しているAmazon Linuxには、

Amazon Corretto(アマゾン コレット)

という、AWS環境に最適化された公式Javaが用意されています。

ターミナルに以下のコマンドをコピー&ペーストして、Enterキーを押してください。

1. Java 17(Amazon Corretto)をインストールする

sudo dnf install java-17-amazon-corretto -y

💡 コマンドの解説

🔹dnf: サーバーの世界の「Amazon(ネット通販)」のようなものです。「これをインストールして!」とお願いすると、インターネットから安全なソフトを探して自動で持ってきてくれます。

🔹-y: 途中で「本当にインストールしていいですか?」と聞かれるのを、「全部YES(はい)で進めて!」とあらかじめ許可しておく便利なオプションです。

画面にズラズラッと文字が流れ、最後に Complete! と表示されれば、搬入は成功です。

2. 🧪 品質確認(テスト):本当にインストールされたか?

インストールが終わったら、「正しく動くか」ステータス確認を行います。

以下のコマンドを実行してください。

java -version

実行結果の1行目に、

openjdk version "17.0.x"

のような文字が表示されていれば、インストールは完了しています。

🌍 ローカルとクラウドの「バージョンのズレ」

無事にJavaがインストールできましたが、ここでインフラと開発の連携において「確認すべき重要ポイント」があります。

それは「Javaのバージョンのズレ」です。

今、私たちが向き合っている2つの画面は「全く別の世界」にあります。

🔸クラウドの世界(AWSサーバー): 今まさに開拓し、安定性の高い「Java 17」のエンジンを搬入しました。

🔸ローカルの世界(手元のPC): 普段開発をしているあなたのPCには、おそらく最新版の「Java 21」や「Java 25」などのエンジンが積まれているはずです。

⚠️ Javaの絶対ルール:「未来から過去へは行けない」

Javaには、システムを安全に保つための厳格なルールがあります。

それは、

新しいバージョン(例:21)で作られたアプリは、古いバージョンのエンジン(例:17)では絶対に動かすことができない

というルールです。

これを実行しようとすると、

UnsupportedClassVersionError

というエラーが出ます😱

この環境のズレを解決するには、実務の開発現場では安定性を重視して

アプリ側(Spring Boot)の設定を、サーバーのバージョンに合わせる

のが一般的です。

今回AWSにインストールしたJava 17安定した長期サポート版(LTS)なので、アプリ側の設計図をこれに合わせていきましょう。


📝 設計図(pom.xml)を書き換えて更新する

手元のPCでVS Codeを開き、Spring Bootアプリの設計図である pom.xml を修正します。

ステップ1:pom.xmlの書き換え

pom.xml の中にある

<java.version>21</java.version>(または25など)

の数字を 17 に書き換えます。

Ctrl + S (Macの場合は Cmd + S)を押してファイルを保存します。

ステップ2:Maven(現場監督)への変更通知

文字を書き換えただけではシステムに反映されません。

「設計図が変わったよ!」裏で動いている現場監督(Maven)に教えてあげます。

VS Codeの画面右下に

Synchronize the Java classpath/workspace

などのポップアップが出たらクリックします。

※または左メニュー「MAVEN」から「更新」をクリックします。

ステップ3:大図書館(GitHub)へ新しい設計図をプッシュする

設計図が変わったので、GitHubのデータ最新状態に更新します。

VS Code左側「ソース管理(枝分かれアイコン)」を開きます。

メッセージ欄に

fix: Javaのバージョンを17にダウングレード

と入力し、「コミット」ボタンを押します。

💡 VS Codeの親切なメッセージ(Gitの仕組み)

コミットボタンを押した時、

「すべての変更をステージして直接コミットしますか?」

というメッセージが出ることがあります。

これはエラーではなく、VS Codeの親切なサポート機能です。

Gitには本来、

1️⃣ステージ(送信用の箱に詰める)

2️⃣コミット(箱をガムテープで封印する)

という2つの手順があります。

箱詰めを忘れて封印ボタンを押してしまったため、

「代わりに箱に入れてから封印しておきましょうか?」

と聞いてくれているのです。

そのまま 「はい」 をクリックして進めて全く問題ありません。

コミット完了後

青いボタンが 「変更の同期(Sync Changes)」 に変わる

ので、それをクリックしてGitHub最新のコードを送信します。

これで、アプリのバージョンサーバーのバージョン「Java 17」で一致しました。


✍️ まとめ

ここまでの作業で、

🔹インフラの基礎となる「権限管理(IAM)」

🔹サーバーをフリーズさせないための「スワップメモリの作成」

🔹アプリを動かすための「Javaエンジンの搬入」

までクリアしました。

さらに、ローカル環境とのバージョンのズレを解消するために、

設計図(pom.xml)を書き換えてGitHubに同期させる

という開発・インフラ連携も行いました。

さて、サーバーJavaのエンジンは搬入しましたが、まだ「データを保存するデータベース」がありません。

次回は、サーバー内装工事の後半戦として、

データベース(MySQL)のインストールと初期設定

を行っていきます。

アプリが裏側でデータを読み書きするための重要な土台作りになります。

最後までお読みいただき、ありがとうございました🙇‍♂️


【プロフィール・作品置き場】

kenichikamoi.com


🎵 Youtube(楽曲一覧)はこちら

www.youtube.com