あらすじ

この記事はAWS Advent Calendar 2020の10日目の記事です。

c5d系やi3などのインスタンスにはNVMeで接続したSSDのインスタンスストアがつきます。このNVMe SSDは停止に伴いデータがなくなるなど制約はありますが、かなり高いIOPSを安いお値段で実現できます。そのため大量のログなどのIOヘビーな一時テータが必要なワークロードのアプリケーションをコスパよく運用することが可能です。

インスタンスストアはファイルシステムが初期化されていないので、そのままではマウントできません。一応AWSのドキュメントには、ボリュームをフォーマットしてマウントするまでのドキュメントがあります。

しかし、こんな手順を起動するたびに手作業でちんたら実行するのは不便きわまりないです。
この記事では起動に合わせてインスタンスストアを自動でマウントする方法について紹介します。

なお、OSはAmazonLinux2を前提にしてます。

ECSホストとして動かす場合

ローカルNVMe SSDをインスタンスが持ってること前提としたECSクラスタを組むケースを想定しています。

当然、その上で動くECSタスクはホストがインスタンスストアをマウントしていることを期待します。そのためホストにはインスタンスストアのファイルシステムの初期化とマウントが終わった後でクラスタに参加してほしいわけです。

これを実現するのは比較的簡単です。たいていの場合ECS用のEC2インスタンスはユーザーデータスクリプトで/etc/ecs/ecs.configにクラスタを書き込むので、その手前でファイルシステムの初期化とマウントを行います。

user-data.sh

#!/bin/bash
mkfs -t xfs /dev/nvme1n1
mkdir /data
echo "/dev/nvme1n1 /data  xfs  defaults,noatime,discard  1  2" >> /etc/fstab
mount -a
echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config

ECS_CLUSTERを書き込む前にマウントまで済ますことでディスクがある状態でクラスタに参加してくれます。

インスタンスストアはOSやコンソールによるリブートでは消えないので再起動はできます。しかし、一度停止状態になるとインスタンスストアのデータはファイルシステムの設定ごと消えてしまうので、次回起動時にはインスタンスストアのマウントができない状態になります。そのためインスタンスストアを持つインスタンスを停止する際は使い捨てて、AutoScalingなどで別インスタンスに入れ替える運用にすることをオススメします。

EC2としてアプリケーションを動かす場合

ECSを使わずに普通のEC2ホストとして利用する場合は少し工夫が必要です。
普通のEC2ホストして使う場合アプリケーションはsystemdで起動することになるのでsystemdでアプリケーションを立ち上げる前にディスクのマウントを完了しておく必要があります。

この場合ユーザーデータスクリプトで初期化するより、ユーザーデータにcloud-initを渡して初期化した方が起動フェーズの早い段階タイミングでディスクをマウントしてくれます。

user-data.yml

#cloud-config

fs_setup:
  - cmd: mkfs -t %(filesystem)s -L %(label)s %(device)s
    filesystem: 'xfs'
    device: '/dev/nvme1n1'
mounts:
  - [ /dev/nvme1n1, /data, xfs, "defaults,noatime,discard", "1", "2" ]

そしてアプリケーションを起動するsystemdのユニットファイルにcloud-configの完了の後に起動する依存設定を追加することで、マウントが完了した後にアプリケーションが起動するように制御ができます。

[Unit]
After=cloud-config.service

[Service]
...

おわりに

以上簡単ですが、インスタンストアの自動マウントについての紹介でした。