まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

最近、VM を扱う機会が多くなりました。何度も色んなパーティショニング要件で Linux をインストールしている中で、これまでちゃんと理解してなかった VG(Volume Group) と LV(Logical Volume) についても理解が深まりました。そのアウトプットの1つとして、ルートディレクトリの容量を無限に増やすことができるような形で Linux VM(VM でなくても OK)を作るための手順等を紹介しようと思い、まずはその前提知識となる VG / LV についてまとめてみます。


【「ルートディレクトリ容量を増やせるようにする」とは?】
Linux に慣れる前に使っていると、最初のうちはあまり深く考えずに VM 等で Linux 環境を用意して使い続けることになり、どこかのタイミングで特定のディレクトリにデータが集まりすぎてディスクが足りなくなってしまう、という経験はないでしょうか?

例えば MySQL データベースとして使っていると、(デフォルト設定だと)そのデータは /var/lib/mysql/ 以下に溜まっていきます。データを多く扱ううちにこのフォルダ以下に大量のファイルが溜まっていくことになります。 また(WordPress のような形も含めて)httpd サーバーとして多くのデータを扱っていると、/var/www/html/ 以下に多くのファイルが溜まっていくことになります。このようにあらかじめ容量に注意すべきディレクトリが分かっている場合は、そのディレクトリに大容量ディスクをマウントして使うとか、その上で LV 化(後述)しておいて後から容量追加できるようにしておく、といった準備が可能です。

問題はそのような大容量が必要なディレクトリ(上述の例だと /var/lib/mysql や /var/www/html )が事前にわからない場合です。最初はそもそも多くのデータを使うつもりもなく作った環境を、後から当初想定していなかった用途でも利用するようになって、あらかじめ容量を拡張できるような準備をせずに使い始めることもあると思っています。しかもこの場合だと利用開始時点では「どのディレクトリに多くのデータが集まるのかもわからない」ので、事前に準備できることがあるとすれば「/(ルートディレクトリ)の容量を後から動的に追加」できるようにしておく必要があります。

特定のサブディレクトリ以下ではなく、ルートディレクトリ自体が拡張可能になっていれば「後からディスクが足りなくなる」ことへの不安はかなり解消されると思っています。


【PV と VG と LV の関係】
以下、"PV", "VG", "LV" という用語を使います。まずはこれらの意味を簡単に紹介します:

PV(Physical Volume): 物理ボリューム
後述する「論理的なボリューム」に対比する意味での「物理的なボリューム」です。論理的なボリュームでは複数のディスクをまとめて1つのディスクであるかのように扱うのに対し、物理的なボリュームでは複数のディスクを(パーティショニングすることはあっても)1つにまとめて扱うのではなく、あくまで1つのディスクは1つとして取り扱う考え方です。厳密には1つの物理ディスクをパーティショニングして1つまたは複数の空間(=ボリューム)として扱います。「論理ボリューム」という考え方をしないのであれば「1つの物理ディスク内の1パーティション=1つの物理ボリューム」です。

VG(Volume Group): ボリュームグループ
PV とは逆に、複数のディスクであっても論理的に1つのディスクとしてみなす、という考え方です。この論理的なディスクをボリュームグループ (Volume Group) と呼びます。

複数の物理的なディスクをまとめて1つの VG を定義します。VG には後からディスクを動的に追加することもでき、そのサイズは追加したぶんだけ増えます。

LV(Logical Volume): 論理ボリューム
Linux のファイルシステムはマウントと呼ばれる仕組みで複数のディスクを1つの空間にマッピングすることができます。この考え方は物理ディスクだけでなく、論理ディスクにも適用できます。

物理ディスク同様に、複数のディスクからなる論理的な1台のディスクをパーティショニングしてマウントすることになります。この論理的なパーティションが論理ボリューム(LV) となり、LV を管理する方法を LVM (Logical Volume Manager) と呼びます。


【2つの物理ディスクを使った場合の比較】
2つの物理ディスク(/dev/sda 容量は 100GB と /dev/sdb 容量は 200GB)を使って Linux マシンを構築するケースを想定し、PV で作る場合と LV で作る場合を比較します。

PV で(というか、LV を使わずに)ルートディスクを作る場合、/dev/sda に1つのパーティション /dev/sda1 を作ってルート(/)にマウントすると仮定すると、100GB のディスク容量を持つファイルシステムが作れます:
2025090501


一方、LV(論理ボリューム)では物理的なサイズやとは関係なく、論理的に定義した空間の容量として考えます。例えば /dev/sda1 を1つの VG とみなし、この VG 全体を1つの LV とみなしてパーティションを作り、このパーティションをルート(/)にマウントすることで 100GB の容量を持つファイルシステムとなります:
2025090502


ここまでだと結局どちらも 100GB の空間を持つファイルシステムが作られることになり、同じことのように見えてしまって、PV と LV の違いが分かりにくいと思います。違いを分かりやすくするためにもう1つ、別に「容量 200GB のディスク /dev/sdb」が手元にあると仮定します。

PV で考えると、この 200GB のディスク /dev/sdb は先ほどの 100GB のディスク /dev/sda とは完全に別のディスクという扱いになります。「容量が 100GB のディスクA」と「容量が 200GB のディスクB」という2つのディスクです。Linux の機能を使って、ディスクAをルートディスク(/)として、ディスクBを /home にマウントすることはできますし、その場合「両方合わせて 300GB」にはなります。しかしディスクAに余裕があったとしてもディスクBに余裕がなければ /home にデータを追加できなくなってしまいます:
2025090503


一方 LV で考えるとこの辺りを柔軟に考えることができるようになります。もともとディスクAをまるごと使って VG を作成していましたが、更にディスクBも同じ VG に追加することができます。この場合、この VG のサイズ(つまり LV のサイズ)は 300GB になります。ディスクBに(物理的な)余裕がなかったとしても、ディスクAに余裕があれば LV にデータを追加可能です。仮にディスクA、B両方の余裕がなくなってしまった場合も、更に別の物理ディスクCを VG に追加することで、動的に VG/LV を拡張することが可能です:
2025090504


1点注意が必要なのは、この論理的な LV の空間が linux のどのディレクトリにマウントされているかです。例えばルートディスクは別に存在していて、 この LV が /mnt にマウントされていた場合、/mnt 以下には最大 300GB のデータを格納することができますが、それ以外のディレクトリ(/usr など)はルートディスクの空きを意識する必要がある、という点です。

なお、1つの VG を1つの LV にする必要はありません。物理ディスクをパーティショニングする時のように、1つの VG から複数の LV に分けて使うことも可能です。



Linux では複数ディスクを論理的に扱う VG/LV という概念があることを説明しました。次回はこの考え方を使って、ルートディレクトリを LV で作り、後からルートディレクトリを拡張する具体的な手順を紹介予定です。




以前に NUCBox というミニ PC を購入した GMKtec 社の(2025/06 時点での)最新モデル、EVO-X2 という格安モンスターマシンを買ってしまいました:
AMD Ryzen AI Max+ 395  EVO-X2 AI ミニ PC

2025061801


CPU に AMD Ryzen AI Max+ 395(16 コア)を搭載し、スペックは2種類から選べるのですが高性能な方だと 128GB メモリ+ 2TB SSD です。そこまで限界に近い状態で使ったわけではないのですが、印象としてさほどうるさいわけでもなく、静かに稼働してくれてます。 円安というハンデの中ですが、このスペックの機種が約 2000 ドルで買えるのはなんとも嬉しい時代になりました。

自分はとある仮想環境の構築のためにメモリ 64GB では足りないと分かっている作業をしていて、この機種ならなんとかなりそう、、と購入したのでした。

ところが実際に使い始めてみると、想定していなかった事態に遭遇しました。タスクマネージャーで見る限り、搭載されているはずの 128 GB のメモリは 128 GB を認識しているかのような表示にはなっているものの、実際には 64GB しか使えないかのようになっていました:
2025061600(1)


64GB だと足りないからこのマシンを購入したのに・・・ というわけで販売元の GMKtec に問い合わせた所、原因と調整方法を教えていただけました。以下、その内容を紹介します。


【なぜ 64GB しか使えないのか】
この機種はメモリそのものは 128GB 搭載されているのですが、出荷状態ではその半分である 64GB が(GPU 用の)グラフィックメモリとして予約されているようでした。そのためユーザーが自由に使えるメモリは(128 - 64 = )64GB になっていた、というのが原因のようでした。

この値は利用者が調整することのできる値になっているので、GPU をどの程度使うつもりなのかによって調整することで実質的なメモリ量を増減することができるとのことでした。


【メモリ量調整手順】
以下でユーザーが利用可能なメモリ量を調整する手順を紹介します。が、この内容が有効なのは PC の BIOS バージョンが 1.04 2025/05/12 以降のものに限られるようです。まずは以下の手順で BIOS バージョンを確認してください。仮に対象日付のものではなかったり、全く異なる BIOS を使っているような場合でも、同じような設定項目があればそこをどうにかすれば(苦笑)なんとかなるかもしれません。

BIOS バージョンを確認するには PC が起動している状態で Win+R をクリックし、"msinfo32" と入力して「システム情報」を起動します。この画面内で「BIOS バージョン/日付」を参照します:
2025061601 (1)


上記だと "1.04 2025/05/14" になっていました。条件を満たしているので、以下の方法でユーザーが利用可能なメモリ量を調整することができます。


メモリ量を調整するには BIOS 画面を起動する必要があります。一度 PC の電源を切ってから電源ボタンを軽く押し、起動画面で ESC キーを連打していると以下のような BIOS 画面が起動します:
2025061802


横の矢印キーで "Advanced" タブを選択します:
2025061803


縦の矢印キーで "GFX Configuration" という項目を選んで Enter キーを押します:
2025061804


再び矢印キーで "iGPU Configuration" という項目を選んで Enter を押し、"UMA_SPECIFIED" を選択します:
2025061805


続いて "UMA Frame buffer size" を選択して Enter を押します:
2025061806


ここで GPU 向けメモリ量を指定します。128 GB モデルの場合、ここは最小で 512MB から最大 96GB まで選択することができます:
2025061807


自分が希望するところまで矢印キーで移動して、Enter で決定します。繰り返しますがこの値が小さいほど、ユーザーが自由に使えるメモリ量は増えます:
2025061808


元の画面に戻るので設定値が自分の希望の値になっていることを確認します:
2025061809


最後に F10 を押して "Save & Exit" 画面に移動して "Save & Reset" を選んで起動します。これで起動した Windows ではここでの変更が反映されて、利用可能メモリが増えているはず、です:
2025061810


多くの人は GPU 目当てでこれを買っているのでしょうか? 私の場合は CPU はそれほどこだわりがなく、メモリ量が最優先だったので「足りない」ことに気付いたのでした。 


最近の PC だとこういうケースは意外と多かったりするのでしょうか。AI や機械学習用途でハイスペック機を使う人も増えているので、初期設定がこのような内容でも困らない人もいるのかもしれませんね。ただ私と同じように悩んでしまった人の助けになれば嬉しいです。

【シリーズリンク】
#内容
1PayPay for Developers へサインアップ
2PayPay API について
3サンプルアプリケーション
4加盟店登録 ←今回


前回の続きです。今回は加盟店登録の手順を紹介します。

以前に紹介した PayPay for Developers にアカウント登録をすることで PayPay API を使ったアプリケーション開発の準備はできていて、実際の決済ではなく仮のお金を使ったテスト環境での決済による動作確認を行うことはできるようになっています(実際にアプリケーションを公開したり運用したりはできないけど、運用する PayPay 決済対応アプリケーションを開発して、公開せずに手元で動かすまではできる、という意味です)。

ただこれだけだとあくまで「(開発したアプリで)試しに使ってみる」段階であって、アプリが完成しても実際のお金を使った本環境での決済に移行することはできません。実際のお金を使った決済ができるようにするには PayPay for Developers のアカウントを作ることに加えて PayPay に加盟店登録をする必要があります。実際の決済をするつもりがなければ本ブログエントリは無視していただいてもいいのですが、私自身が試しに手続きを行った記録を公開する目的で紹介させていただきます。


【加盟店登録の法人登録と個人事業者登録の違い】
では PayPay 加盟店登録する手順を紹介します。PayPay for Developers アカウントを取得済みであることが前提となりますので、まだ取得されていない場合は以前の内容を参照いただいて取得しておいてください。

加盟店登録をする上で最初に決めておく必要のある項目があります。それは「法人登録」にするか、「個人事業者登録」にするか、ということです。どちらか1つを選んで登録することになります。

私のように経営主体となる法人を持っておらず、あくまで個人開発者としてサービスを運用することを想定するのであれば事実上選択肢はなく、個人事業者登録一択になります。個人事業者登録のメリットはなんといっても手続きが簡素であることです。提出書類も本人確認書類程度だし、公開するアプリケーションに必要な情報(ページ)が用意されていれば審査もさほど面倒ではありません※。

※法人登録したことないので、あくまで主観です。

一方、事業法人としてのサービス運用を行う場合は法人登録する選択肢もあります。こちらは手続きは比較的面倒ではあるのですが、個人事業者登録では使うことのできない機能(例えばサブスクリプション決済機能)もフルに活用することができ、より柔軟な機能実装や運用が可能になります。

以下では個人事業者として加盟店登録する手順を紹介します。ただこの手続きを最後まで行うには該当のウェブアプリケーションが既に公開されていて、その URL やサーバー IP アドレスを入力できる状態になっている必要があります。そこまで準備ができている状態で先に進めるようになる点にご注意ください。


なお、この手続きに関する PayPay の公式ドキュメントはこちらになります:
https://integration.paypay.ne.jp/hc/ja/article_attachments/4632569873039


【PayPay に個人事業者として加盟店登録する手順】
PayPay に個人事業者として加盟店登録する手順は2段階に分かれた入力作業を終える必要があります。まず第一段階の手順を紹介します。

PayPay for Developers にログインし、ダッシュボード画面から「アカウントの作成」と書かれた部分をクリックします:
2025060801


「加盟店登録をしましょう」というダイアログが表示されるので「今すぐ申し込む」をクリックします:
2025060802


すると申し込みフォームが表示されます。自分でアプリを作って運用する場合は「ユーザへのサービス提供の主体となる事業者」を選択します:
2025060803


すると質問項目が増えます。まずサービスの販売形態は「Web サービス/アプリ」にチェック、ご利用のサービスは「ウェブペイメント/動的ユーザースキャン/アプリコール」をチェック(サブスクである「継続課金」を使ってみたいところではありましたが・・・ 個人事業主は上のみ選択可能です)、最後に「お申込みフォームへ」をクリックします:
2025060804


すると画面が「PayPay オンライン加盟店のお申込み」ページに遷移します。自分の名前と連絡先電話番号、事業形態(個人事業主)を入力して、最後に「確認する」をクリックします:
2025060805


以下のような確認画面が表示されるので「申し込み開始」ボタンをクリックします。これで第一段階が完了です:
2025060806


この後、以下のようなページに遷移し、本登録である第2段階のフォーム入力となります。画面上部の「残り未完了項目」(必須項目で未入力のもの)がゼロにならないと先へ進めません:
2025060808


以下、要注意な部分のみ紹介します。まず個人事業主としての代表電話番号や住所の入力が必要です。ここには自分の電話番号や住所を記載します:
2025060809


次に開発して公開することになるウェブサービスの内容を記載する項目があります。名称や年商(予定)を記載します:
2025060810


販売形態は(ウェブサービスであれば)「web/アプリ」を選択し、サービス内容の詳細を記載・選択します。 なおこの中で「お取り扱い商品詳細」を指定するのですが、ここで指定する項目によって決済システム利用料(=PayPay 側に支払う手数料)が決まります:
2025060811


またここで実際に公開するウェブサービスの URL 等の情報が必要です。この中には特定商取引法に基づく表記の URL や(個人事業主としての)コーポレートサイトの URL も必須入力項目として必要な点に注意してください:
2025060812


更に決済サーバー(アプリケーションが稼働するサーバー)のグローバル IP アドレスも必要です:
2025060813


実決済を伴うサービスの申請となるため、緊急連絡先の登録が必要です。PayPay 決済サービス側の障害情報などもここで登録したメールアドレスに送付されます:
2025060814


規約等の内容を確認し、問題なければチェックを入れます。入力が完了したら「保存して次へ」をクリック:
2025060815


次に振り込み関する情報入力ページに遷移します。最初に入金サイクルを指定します:
2025060816


次に売り上げを入金してほしい金融機関を指定します:
2025060817


特定の商品を扱う場合はその資格書類が必要になるので、内容について該当項目があればチェックします。入力が完了したら「保存して次へ」をクリック:
2025060818


最後は本人確認書類の登録画面です。最初は入力内容の確認と、必要であれば(本人確認書類の登録前に)修正します:
2025060819


本人確認書類の登録に移ります。自動車運転免許など、登録する書類を選択し、指示に従って画像ファイルをアップロードします:
2025060820


必要な全ての画像ファイルをアップロードしたら「次へ」をクリックします:
2025060821


最後に内容確認画面が表示されます:
2025060822


内容に修正が必要なければ「内容を確認して申込む」ボタンをクリックします。これで登録作業そのものは完了です:
2025060823

私の場合は入力の数時間後に電話がかかってきて、いくつかの内容について電話確認が行われました。まあ電話番号の確認も兼ねたものだと思います。電話対応の後、数日後に以下のようなメールが送られてきました:
2025060824


メール本文にも書かれていたように、実際に利用開始できるようになるまでここから更に数日必要なようでしたが、手続きとしては無事に完了することができました。


【まとめ】
以上、4回に渡って PayPay API を使ったオンライン決済対応アプリケーションの作り方や、その前提となる PayPay for Developers アカウントの取得方法を紹介してきました。

アプリケーション開発に関しては、以下の点に注意する必要があると感じました:
・単に PayPay で決済するだけなら実装はシンプルでさほど難しくない
・一方で(テスト用のお金ではなく)実際のお金で決済するアプリを公開する前提で考えると、返金処理などにも対応した設計が必要になり、そのためには決済トランザクションをデータベースなどに記録して、後からどのトランザクションに対する返金なのかを照会できる仕組みも併せて必要

また今回は個人事業主アカウントしか作れなかったので、用意したサンプルもそこまで複雑な API を実装していないのですが、いずれは(現在、法人契約でないと使えない)サブスクリプション API も使えるようになったらいいなあ、、と思っています。






このページのトップヘ