Scribble at 2023-09-29 10:56:54 Last modified: 2023-09-29 12:03:01
今月の後半は、SAKURA インターネットのクラウドから当社で運用しているサイトの全てを AWS に移設していた。受託で構築・管理している某県観光関連のサイトは動かせないが、他のサイトはインスタンスの運用方法を改めて、もっとコストが安くて経理上の問題が解決できるため（AWS は AMI サブ・アカウントごとに請求書を分割できる）、AWS へ移設することとした。ぜんぶで６サイトの DNS レコードを変更し、殆ど最低スペックのインスタンスと 30 GB ていどの EBS に、SAKURA では個別にインスタンスを建てていた全てのサイトを突っ込んだ。
もちろん、本来はプライバシーマークを運用しているレベルの会社では不適切なことかもしれないが、それはデータを保存したり、個人情報の取り扱い手段が異なるサイトを一つにまとめた場合の話であろう。これら６サイトは、まず運営主体が全て当社であるから情報管理のポリシーが同一である。そして、これら６サイトのうちで個人情報を取得するのは当社のコーポレート・サイトだけである（問い合わせフォーム）。受託のステージング・サーバもあるにはあるが、かつては「堂島（というよりも＊通関西支社）の神」と言われた人間に作業させておいて構築・運用のコストを全く回収できていないコンテンツなんて、事実上の物置である。誰がまともな工数などかけるものか。片手間でも俺のようなエンジニアが運用しているからこそ、15年にわたって情報漏洩も動作不良もないのだ。
さて、それはそうと、AWS で仕事している IT アーキテクトやサーバ・エンジニアならご承知だと思うが、AWS でインスタンスを建てても、それだけでは幾つかのサービスが利用できない。特にメールの送信というサービスは、クラッカーやスパム業者どもが自動でメール・サーバのインスタンスを作っては壊すというインチキなりあからさまな犯罪行為へ対抗するために、利用者が操作できない Amazon だけが管理しているグローバルなインターフェイスで制限をかけている。この場合、やることは次のどちらかになる。一つは、GMail API などを使って AWS の制限を迂回してメールの送信を外部のサーバに肩代わりさせること、そしてもう一つは AWS にメール送信の許可を申請して25番ポートを使わせてもらうことだ（インスタンス側でファイアーウォールの設定を変えたり、EC2 インスタンスのインバウンド・ルールで25番ポートを開こうと、申請が通らなければポートは使えないからだ）。
２年ほど前に AWS を利用し始めたときも、同じ事情で AWS に申請を出してメールを送信できるようにしてもらった。
https://console.aws.amazon.com/support/contacts?#/rdns-limits
何回か、メール・サーバのセキュリティやメールを送信する目的について（あたりまえだが英語で）やりとりしてから、そう重大な無知や誤解がない限りは申請が許可されるだろう。そうすると、PHP で mail() 関数を使ったメールの送信が自由にできるようになる。なお、メール送信を許可してもらうにはアンチウイルスのプログラムを導入するといった説明が必要になる。（典型は ClamAV のようなアンチウイルス・ソフトの導入だが、これのデータベースを初期化するのに相当な負荷がかかる。僕が運用しているインスタンスで試すと、瞬く間に load average が 90 % を越えてしまい、公開しているサイトの表示が止まってしまったため、このインスタンスでの運用は無理と判断した。）
なお、方法として最初に GMail API などの外部サービスを使った送信方法もあると紹介したが、これはいわば「脱法行為」に近いため、オススメしない。たとえ Google などのサービスで正当に API key などを取得したり OAuth 2.0 などの正当な手続きをするとは言っても、やはりサービスの運用として望ましいとは言えないからだ。そして、現実的な問題もある。たとえば、GMail API を利用して PHP でメールを送信する場合に、「Gmail API クライアント・ライブラリ」というライブラリが Google の公式アカウント（GitHub）からリリースされているが、これの PHP 8.2 に対応する最新版ですら正しく動作しない。autoload.php を読み込むだけで 500 Internal Server Error となってしまい、ひたすらバッド・ノウハウを調べまくるか、直にライブラリの PHP コードを修正させられる羽目になる。こういうブラックボックスを使ったシステムの運用は、正直なところ問題が起きた時点でサービスの提供やサイトの運用をやめても大した影響がない個人の用途にとどめておくほうがよく、企業、なかんずく公開しているサービスで利用するべきではないと思う。やはりエンジニアは自分でコードを書くのが基本だ。それから、この手のライブラリの使い方を調べると分かることだが、GMail API を利用して PHP でメールを送信するという与件に該当する説明の殆どが、GCP (Google Cloud Platform) を前提にしていて、重大な依存性や前提条件を無視して解説しているため、全く汎用性がない。何の参考にもならないのだ。たとえば、API key だけを使ってメールを送信できるなどと書いているブログ記事もあるが、それは GCP で API key だけで動かせば、それだけで課金できるからなのだ。GCP と関係のないサーバやインスタンスで同じことをしても無意味である。