Amazon EBSにおけるボリュームサイズの拡張

AWS, EBS, グループマネージャー

■ はじめに

レコチョクでグループマネージャー（以下、GMR）をしている山本（耕）です。

レコチョクには、エンジニア組織を構成するためにいろいろなロールがあります。
GMRは、部門およびグループの「ヒト、モノ、カネ」を管理して、グループメンバーのパフォーマンスを高めることを主な役割としています。そのような役割なので、システム開発の業務はグループメンバー（以下、メンバー）に委任することが多いです。

しかし、メンバーの成長やグループの成果を考えた時、委任するより自分自身で手を動かしたほうが良いことが往々にしてあります。そのような流れでGMRでも手を動かして実施した技術的な話題を記事にさせて頂きます。
※より手を動かしながらエンジニアのパフォーマンスを最大化するエンジニアリングマネージャー（EM）というロールもあります。

■ 今回のテーマ

Amazon EBSにおけるボリュームサイズの拡張

■ 目次

  • 背景
  • 実施手順
  • まとめ

■ 背景

弊社では、デジタル音源の配信事業の中で、アーティストの写真（以下、ア写）や楽曲のジャケット写真（以下、ジャケ写）を管理して活用しています。それらの画像を各サービスで利用してもらうために画像変換システムを構築して、API経由で各サービスに提供をしています。

レコチョクでは開発案件の合間にシステム構成の最適化を実施しております。その一環で、各サービスに向けに複数環境（サーバグループ）を提供していたのですが、これを統合する意思決定をしました。

EC2インスタンス上でアプリケーションが稼働していますが、CPU・メモリ使用率やレイテンシに余裕があることは把握していたので、他の環境のAPIリクエストを統合先の環境へAPIリクエストされるように対応をしました。
しかし、EBSのストレージサイズの考慮が漏れており、APIリクエストの増加によりアクセスログが増加、閾値の超過アラートが発砲されました。ログの保存期間を減らすことは運用リスクがあるため、EBSのストレージサイズの増加で対応をすることにしました。

■ 実施手順

【前提条件】

  • 対象のAWSアカウントのIAMが発行されており、AWSコンソールにログインが出来ること。
  • IAMにEBSへの変更が可能な権限が付与されていること。
  • EBSのストレージサイズを拡張したいEC2インスタンスにログインが出来ること。
  • 起動しているEC2インスタンスのOSは、AmazonLinux2であること。

【対象EC2インスタンスの状態確認　その１】

手順１．対象のサーバにアクセスして、”lsblk”コマンドと”df”コマンドで現時点の状態を確認する。
[user@img-xxx-rnn-i-00000000000 ~] lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  150G  0 disk
mqxvda1 202:1    0  150G  0 part /
xvdb    202:16   0 1000G  0 disk /recochoku/data/img
 
[user@img-xxx-rnn-i-00000000000 ~] df -h
devtmpfs         7.4G     0  7.4G    0% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm
tmpfs            7.4G  428K  7.4G    1% /run
tmpfs            7.4G     0  7.4G    0% /sys/fs/cgroup
/dev/xvda1       150G  122G   29G   82% /
/dev/xvdb        985G  432G  503G   47% /recochoku/data/img
tmpfs            1.5G     0  1.5G    0% /run/user/20342

※今回の対象は、「xvda」ディスク（EBS）の「mqxvda1」パーティションになります。
※”lsblk”コマンドで表示される「mqxvda1」と”df ”コマンドで表示される「/dev/xvda1」は同じ意味となります。
※この後の作業は、「xvda」ディスクを拡張して、「/dev/xvda1」パーティションに割り当てる作業となります。

【「xvda」ディスクの拡張】

手順１．対象のAWSコンソールにアクセスする。
手順２．EC2 > Elastic Block Store > ボリュームのメニューを開く。
手順３．EBSの一覧が表示されるので、対処のEBSを選択して、「変更」ボタンを押下する。
手順４．サイズ (GiB)を必要なサイズ（今回は、300GiB）に変更する。
手順５．ボリュームのステータスが「OK」になることを確認する。

【対象EC2インスタンスの状態確認　その２】

手順１．再度、対象のEC2インスタンスにアクセスして、現時点の情報を確認する。
[user@img-xxx-rnn-i-00000000000 ~] lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  300G  0 disk
mqxvda1 202:1    0  150G  0 part /
xvdb    202:16   0 1000G  0 disk /recochoku/data/img

※ 「xvda」ディスクは拡張されているが、「mqxvda1」パーティションへは未割当のため、まだ拡張が出来ていません。

【パーティションへの割り当て】

手順１．以下のコマンドを実行して、「/dev/xvda1」パーティションにストレージを割り当てる。
[user@img-xxx-rnn-i-00000000000 ~] # growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=314568671 end=314572767 new: size=629141471 end=629145567

※”growpart”コマンドを実行するときは、”df”コマンドで表示される「ファイルシステム名」＋” “＋「1（パーティション番号）」で実行します。
※”df”で表示した場合、「ファイルシステム名」と「パーティション番号」が連結され表示（/dev/xvda1 ）されています。なので、コマンドを実行する場合は、「ファイルシステム名」と「パーティション番号」に分解して指定して下さい。
※”df”コマンドで表示される内容が環境により少し違う場合があるので、この通り表示されていない場合があります。

手順２．”lsblk”コマンドと”df”コマンドで結果を確認する。
[user@img-xxx-rnn-i-00000000000 ~]  lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  300G  0 disk
mqxvda1 202:1    0  300G  0 part /
xvdb    202:16   0 1000G  0 disk /recochoku/data/img
 
[user@img-xxx-rnn-i-00000000000 ~] df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         7.4G     0  7.4G    0% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm
tmpfs            7.4G  436K  7.4G    1% /run
tmpfs            7.4G     0  7.4G    0% /sys/fs/cgroup
/dev/xvda1       150G  122G   29G   82% /
/dev/xvdb        985G  438G  497G   47% /recochoku/data/img
tmpfs            1.5G     0  1.5G    0% /run/user/20342

※”lsblk”コマンドの結果には反映されており「mqxvda1」が300GiBに拡張されていますが、”df”コマンドの「/dev/xvda1」には反映されていません。
※これは、OSがパーティションに割り当てたボリュームを認識していないためになります。

【OSに認識させる】

手順１．以下のコマンドを実行して、「/dev/xvda1」に割り当てたボリュームをOSに認識させる。
[user@img-xxx-rnn-i-00000000000 ~]  xfs_growfs -d /
meta-data=/dev/xvda1             isize=512    agcount=76, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1 spinodes=0
data     =                       bsize=4096   blocks=39321083, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 39321083 to 78642683

※”xfs_growfs ”コマンドは、-dオプションの引数にマウント位置（今回は、/）を指定します。
※OSが、AmazonLinux2の場合、XFSというファイルシステムのため、コマンドがxfs_growfsとなります。
※別のファイルシステムの場合（例えばBtrfs、Ext4、Ext3、Ext2 など）は、コマンドが違うため注意が必要となります。

手順２．”df”コマンドで結果を確認する。
[user@img-xxx-rnn-i-00000000000 ~] df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
devtmpfs         7.4G     0  7.4G    0% /dev
tmpfs            7.4G     0  7.4G    0% /dev/shm
tmpfs            7.4G  436K  7.4G    1% /run
tmpfs            7.4G     0  7.4G    0% /sys/fs/cgroup
/dev/xvda1       300G  122G  179G   41% /
/dev/xvdb        985G  438G  497G   47% /recochoku/data/img
tmpfs            1.5G     0  1.5G    0% /run/user/20342

※”df”コマンドの「/dev/xvda1」に反映されてボリュームが拡張されたことを確認することが出来ます。

■ まとめ

Amazon EBSにおけるボリュームサイズの拡張方法でした。
以下のAWSの公式ドキュメントを参考にして実施したのですが、一部、表示内容が違う部分があり、上手く行かなかったので、少し丁寧に整理してみました。

■ 最後に

最後まで読んでいただき、ありがとうございます。
レコチョクでは、ソフトウェア開発だけでない幅広い技術を経験する環境でチャレンジしたいメンバーを募集しています。興味のある方は、レコチョク （採用ページ）からぜひご応募下さい！

この記事を書いた人

山本 耕琢（コウタク）
山本 耕琢（コウタク）意識低い系エンジニア 兼 マネージャー
レコチョクの楽曲情報の検索や、決済/会員情報、 レコメンド情報などを扱う、レコチョクAPIの運用と改善を担当しています。主にプロジェクト管理をやっています。技術力は低めですが、気づきがあったことなどを更新していきます。

AWS, EBS, グループマネージャー