システム奮闘記：その109

メールサーバーをレンタルサーバーへ移行

(2018年12月13日に掲載)

はじめに

　2000年に10万円のDOS-V機にLinuxをインストールして以来
18年間、自社でメールサーバーを運用していましたが
レンタルサーバーへ移行になりました。今回は、その話を書きました。


レンタルサーバーへ移行の経緯

　2018年6月25日、事件が起こった。

　重要なサーバーが停止してしまった!!

故障したサーバーのネットワーク上の位置
DMZ内に置いていたサーバーが故障した。 このサーバーはメール中継をしていたため、外部からやってきたメールを 社内のメールサーバーに転送する役目を担っていた。 それだけではなく、社外向けのDNSサーバーだった。 ホームページは、この時、すでにレンタルサーバーに置いていたが DNS検索ができないため、うちの会社のホームページが閲覧できなくなった。 顧客向け検索システムも、このサーバーだったため、顧客が使えなくなる。 EC-CUBEを改良して運用していたネット販売システムも使えなくなった。 EC-CUBEについては「システム奮闘記:その65」(EC-CUBEでネット販売システム構築)をご覧ください。

　どんな故障か見てみたら、復活不可能な状況だった。

サーバーのコンデンサーが破裂していた
サーバーのマザーボードにある電解コンデンサーが破裂していた。 そのためサーバーが動かなくなった。2008年に購入だったため完全に寿命だった。 このマシンはxenserverを使って仮想化していた。 詳しくは「システム奮闘記:その88」(xenserverの導入とインストール)と 「システム奮闘記:その89」(xenserverの運用・管理)をご覧ください。

　10年間、よく動いてくれたと思ったが、感傷に浸っている暇はない。

　このサーバーだが仮想化していた上、このサーバーと同じCPUを使っているマシンは他にない。

　ハードディスクのデータを取り出されへん!!

　だが、運は尽きていなかった。

　検索システムのプログラムのバックアップをとっていた!!

　だった。
　この事件の数ヶ月前にプログラムのバックアップをとっていたのだ。
　もし、バックアップをとっていなかったと思うと、とんでもな事態になる所だった。

　だが、いかに復旧作業を行うかが課題になった。
　1からサーバーを構築、各種設定をするしかない。

　そこで、まずは社内で余ったパソコンがないかと探した。
　すると2台あった。どれもWindowsXPのパソコンだった。

　だが、Linuxの特性である

　古いパソコンでも動く!!

　だった。

　Linuxのディストリビューションだが、CentOSを使っている。
　CentOSでも色々バージョンがあるが、1台目はインストール途中でコケた。
　いくつかのバージョンを試してみたが、うまくいかず・・・

　復旧できへんかもしれへん!!

　という不安がよぎる。
　2台目のパソコンだが、無事、インストールできたのがCentOS6.2だった。

　久々のApacheやPHPのインストール。インストール方法を思い出しながら作業を進めた。
　ライブラリ依存があるので、途中で、ソースコンパイルがコケると、必要なライブラリを探して
RPMファイルになっているライブラリをインストールしていった。

　復旧できないかもしれない不安との戦いだった。

　晩20時頃になって、ようやくDNS、メール中継、顧客向け検索システムが復旧した。


レンタルサーバーへの移行を決める

　サーバー故障の事件で、サーバーの外部委託の雰囲気が出てきた。
　だが、下手に業者にサーバー構築してもらうと高い上、技術力のない業者だったら
目も当てられない。
　そこで思いついたのは・・・

　レンタルサーバーへの移行

　これだと業者にWindowsサーバーを構築してもらうよりも安上がりだ。

　下準備として上層部に、レンタルサーバー移行を検討している事を伝えた。
　レンタルサーバーへ移行した方が安上がりだからだ。


レンタルサーバーを紹介してもらう

　レンタルサーバーといっても、どこが良いのかわからない。
　困っている所に、別件で、ある会社から紹介された、まともなコンサルが来社した。
　その時に、お勧めのレンタルサーバーを尋ねると

　さくらインターネットか、かごやをお勧めします

　だった。

　比較すると、うちの会社にとって良いのは、さくらインターネットだったため
さくらインターネットを選ぶ事にした。


さくらインターネットの設定

　レンタルサーバーでメールの送受信を行うのだが、どういう仕組みになっているのか
考える必要があった。

うちの会社のサーバーと、さくらインターネットのサーバー
うちの会社の場合、社外向けのDNSサーバーがある。

　現状では、DNSサーバーで設定しているMXレコードで記述している
メールの配達先は、うちの社内のドメインを指定している。

XXXX.co.jp.	IN	MX	10	mail.XXXX.co.jp.

　そのため外部から、うちの会社宛てのメールは、全て、うちの会社のサーバーに届く。
　図式化すると以下のようになる。

MXレコードで記述しているメールの配達先は、うちの社内のホストを指定
メールの配達先が、うちの会社のサーバーなので、うちの会社のサーバーに届く。

　そして、さくらインターネットにメールサーバーを移行させた場合
DNSのMXレコードの設定内容が次のように変える。

XXXX.co.jp.	IN	MX	10	YYYY.sakura.ne.jp.

　図式化すると以下のようになる。

MXレコードで記述しているメールの配達先は、さくらインターネットのホストを指定
外部から、うちの会社宛てのメールは、さくらインターネットのホストに行くようになる。

　実際に、こういう設定で正しいのかどうか確認する必要があった。

　さくらインターネットに契約する前にしておかないと具合が悪い。
　そこで、さくらインターネットに以下の問い合わせをした。

　さくらインターネットからの回答を見る。
　設定の手順を読んでいくと・・・

　これはいける!!

　と思った。


さくらインターネットと契約

　さくらインターネットのレンタルサーバーの契約をする事になった。
　契約といっても、ネット上で選択して、支払いをするだけなので手軽だ。

　「さくらのマネージドサーバ HDDプラン」を選んだ。
　メールだけなら、もっと安い物でも良かったのだが、WevDAVを使って
ファイルサーバーを構築するため、一番、高いプランを選ぶ事になった。

　それが9月の初めだった。
　数日後、北海道で大地震が発生し・・・

　北海道で大規模停電

　になった。
　さくらインターネットは、石狩にデータセンターを保有しているが
全く正常に稼働していた。
　さくらインターネットの危機管理体制の凄さに驚いた。


複雑なメール配信

　だが、メールの移行する際、厄介な問題が立ちふさがっていた。
　メールサーバーの切り替え方法だった。何せ複雑な配信を行っているからだ。

うちの会社のメール関連のサーバー構成
DMZに中継用のメールサーバーがある。 LAN内部にメールのウイルス検査を行うウィルスフィルターのサーバーと メールを受信するメールサーバーがある。

　余談だが、ウイルス検査のウイルスフィルターは、F-Secure社のアンチウィルス Linuxゲートウェイを使っています。
　それについては「システム奮闘記:その43」(エフセキュア社のLinuxウイルスゲートウェイの設定)をご覧ください。


　さて、外部からメールがやってきた場合、どういう経路をたどるのか説明します。

外部からメールがやってきた場合、どういう経路をたどるのか(1)
外部からメールがやってきた際、DMZ内にあるメール中継用のサーバー(メールゲートウェイ)に届きます。

　DMZ内のメール中継用サーバーがメールを受信した後、LAN内のウイルス検査を行うサーバーへ
メールが転送される仕組みだ。

外部からメールがやってきた場合、どういう経路をたどるのか(2)
DMZ内のメール中継用サーバーが受信したメールは、LAN内にある ウイルス検査のサーバーに中継される。

　ウイルス検査が終わった後、さらにLAN内のメールサーバーへ転送される。

外部からメールがやってきた場合、どういう経路をたどるのか(3)
ウイルス検査が終わったメールは、メールサーバーに中継される。

　利用者がパソコンからメール送信した場合、どういう経路でメールが配信されていくのか説明する。

外部へメールを送信するための経路(1)
まずはパソコンからウイルス検査のサーバーへメールが送信される。

　ウイルス検査が終わった後、LAN内のメールサーバーへ転送される。

外部へメールを送信するための経路(2)
ウイルス検査が終わった後、LAN内のメールサーバーへ転送される。 各パソコンのメールソフトの設定で、SMTPサーバーをウイルス検査のサーバーにする事で 仮にパソコンがウイルス感染しても、ウイルスメールをまき散らす事を防止する事ができる。

　そこから、さらにDMZのメールゲートウェイへ中継される。

外部へメールを送信するための経路(3)
DMZのメールゲートウェイへ中継される。 メールゲートウェイを中継する事で、発信元

　DMZ内のメールゲートウェイから外部のサーバーへメールが配信される。

外部へメールを送信するための経路(4)
DMZ内のメールゲートウェイから外部のサーバーへメールが配信される。

　複雑なメール配信になっているため

　どうすれば円滑にレンタルサーバーへ移行できるか

　が問題になってくる。

メールサーバーの移行手順

　既存の自社のメールサーバーから、レンタルサーバーへどうやって移行させるか。

　一時的にメールの運用を停止して、その間に既存のメールサーバーから
さくらインターネットのサーバーを切り替える方法があるのだが・・・

　メールサーバーを止めるわけにいかへん!!

　という問題がある。


　そこで色々考えている間に良い方法を思いついた。

　まずは受信だけを、さくらインターネットのサーバーへ移行させる

　という方法だ。


　メールの受信は、さくらインターネット。メールの送信は、うちの会社のメールサーバー。
　幸い、技術的には方法を確立していた。

fallback_transportの設定

　うちの会社のメールサーバーのソフトはPostfixを使っていた。

　この時、役に立ったのがWebメールのScalixを導入した時に覚えた
Postfixの「fallback_transport」という設定項目だった。

　どういう時に使うかというと、例えば、example.comという同一ドメインを使いながらも、
メールサーバーを2台にせざる得ない場合があるとする。

　具体例として、Scalix導入の際が、既存のメールサーバー( Postfix )と、
Scalixをインストールしたサーバーは別々だったため、以下のようにした。

example.comドメイン宛てのメールをメールサーバーに送る
example.comドメイン宛てのメールが、まずは既存のメールサーバーに届く。

　そして既存のメールサーバー内で「suga」というアカウントの有無を調べる。

「 suga 」というユーザー名がサーバー上にあるかどうかを判断する
メールサーバー上にあるユーザデータベースから「suga」の有無を調べる。

　もし、sugaというユーザーがなければ、指定された転送サーバーへメール転送される。

sugaというユーザーがなければ、指定された転送先のサーバーへ転送される
最初のメールサーバーに「suga」というユーザー名がなければ Postfixの転送機能で、別のサーバーへ転送する事ができる。

　この仕組みを応用すれば、うちの会社のメールサーバーに来たメールを
さくらインターネットのサーバーに転送できる。

　もし、うちの会社のメールサーバーから全員のアカウントを削除すれば
以下のメール配信の仕組みを構築できる。

やってきたメールは、一度、メールサーバーでユーザー名の有無を確認
やってきたメールは、メールサーバーに届け、メールサーバーでユーザーの有無を確認する。

　だが、該当のアカウントが削除されているため、メールサーバーは
「該当のアカウントがない」と判断し、メールをさくらインターネットのサーバーへ転送する。

メールサーバーに該当アカウントがなければ、さくらインターネットで受信が可能
該当のアカウントがないため、さくらインターネットにメールが転送される仕組みになる。

　Scalix導入は不発に終わったのだが、この時に覚えた知識は役に立った。
　Scalixについては「システム奮闘記:その87」(Webメールのscalixのインストール)をご覧ください。


　さて、メールの受信を、さくらインターネットのサーバーに移行させる手順を考える。

　うちの会社の場合、サーバーに届いたメールは、パソコンに取り込むpopを採用している。
　そのため、一度に全員のメールアドレスの受信を、さくらインターネットに移行させるとなれば
以下の手順を踏む必要がある。

　だが、この場合、問題が発生する

　短時間のうちに(3)を実行させるのが不可能

　だった。


　そこで知恵を絞った。すると良い方法が思いついた。

　1人づつ移行させていく

　だった。

　以下の手順になる。

　これだとメールサーバーを止めなくても大丈夫な上、(2)を行うにも
相手の都合に合わせて行う事ができる。


　この時、大事なのは

　全員を移行させるまでは、メール送信(SMTPサーバー)は

　うちのメールサーバーのまま

　にしておくことだ。


　もし、送信メールサーバー(SMTPサーバー)まで移行させてしまうと厄介な問題が起こる。

送信メールサーバー(SMTPサーバー)まで移行させてしまう
パソコンからさくらインターネットのサーバーにメールを送信する形になる。

　もし、sugaというアカウントを移行させないまま、SMTPサーバーを
さくらインターネットに移行させた場合を考える。

社内にあるsugaというアカウント宛てにメールを送信する
sugaというアカウントは、まだ移行させていないとする。 その場合でも、SMTPサーバーを、さくらインターネットに変更する事で suga宛てのメールも、さくらインターネットへ送信される。

　だが、sugaというアカウントは移行させていないため
さくらインターネットのサーバーには「そんなアカウントはない」となり、メールは戻ってくる。

該当アカウントがないと判断され、メールは戻ってくる
さくらインターネット上のレンタルサーバーには「suga」が登録されていないため 該当アカウントがないと判断されてしまい、メールは戻ってくる。

　そのため全員のアカウントを、さくらインターネットに移行させるまでは
SMTPサーバーは、うちの会社にある既存のメールサーバーにしておく必要がある。


さくらインターネットのメールサーバーの設定

　さくらインターネットでのメールサーバーの設定を行うのだが
完全に、さくらインターネットが配布している手順書の丸写しだ。

　ブラウザーを使って手軽に設定できる

　のだ。
　Linuxを触り始めてから、ファイル記述で設定してきた私からすると、隔世の感がある。


　ブラウザーでサーバーコントロール画面を開く。

さくらインターネットのサーバーコントロール画面(ログイン画面)
ユーザーIDとパスワードを入力する。

　ログインすると、以下の画面が出てくる。

さくらインターネットのサーバーコントロール画面
ここで様々なサーバー機能の設定を行う事ができる。

ドメイン設定

　さくらインターネットのサーバーでメール受信をできるようにする必要がある。
　そのため、うちの会社のドメインを登録する必要がある。

　便利なのは

　他社で取得したドメインを移管せずに

　さくらインターネットでも使える

　という事だ。

　そこでサーバーコントロール画面のドメイン設定を触る事にした。
　もちろん、マニュアルの丸写しなのだ。

サーバーコントロール画面のサイトに関する設定
ここで青く囲んだ「ドメイン/SSL設定」を選ぶ。

　するとドメイン設定の画面が出てくる。

サーバーコントロール画面の「ドメイン/SSL設定」
青く囲んだ「新しいドメインの追加」を選ぶ

　さくらインターネットで、うちの会社のドメインは取得していない。
　他社で取得したドメインなので、そのまま前に進む。

サーバーコントロール画面:他社ドメイン追加
さくらインターネットで取得したドメインがあれば選択肢に出てくるようだが それはないため「他社のドメインを移管せずに使う」の選択肢しか出てこない。 もちろん、そのまま進める。

　すると登録したいドメインの記入画面が出てくる。

サーバーコントロール画面の「ドメインの追加」
登録したいドメイン名を記入する。 今回は、うちの会社のドメインを記入する。

　すると確認画面が出てくる。

サーバーコントロール画面のドメインの追加の確認
ここで「送信」を押す。

　すると設定完了の画面が出てくる。

サーバーコントロール画面のドメイン追加の設定完了の画面
うちの会社のドメインを登録したのだが、反映されるまで数時間〜2日間はかかるようだ。

　これでドメインの登録が終わった。


さくらインターネット上で、ユーザー登録

　ドメインの登録後は、ユーザー登録を行う。
　ユーザー登録をしないと、メールの受信ができないからだ。

　もちろんメールだけでなく、ftpやWebDavも使えないのだ。
　さてユーザー登録をしていく。

サーバーコントロール画面のユーザーの画面

　メールとユーザー管理の欄を見る。

サーバーコントロール画面のメールとユーザー管理の画面
ユーザー管理を選ぶ。

　この時点では、ユーザー登録されていないため、ユーザー一覧は出てこない。

サーバーコントロール画面のユーザー一覧画面
まだユーザー登録されていないため、一覧が出てこない。 青く囲んだ「ユーザー追加」を選ぶ。

　ここでユーザー登録を行う。
　試験的に「suga2」のユーザー登録をする事にした。

サーバーコントロール画面の新しいユーザーの追加画面
この時、メール利用、ftp利用、ファイル共有の有無に印をつける事ができる。 ユーザーによって利用制限ができるのだ。 メールでも迷惑メールやウイルスフィルターの有無を個人別に行えるのだ。 うちの会社では、ウイルスメールは除去するが、迷惑メールは100%の選別ができないため 迷惑メールは、そのまま通す事にしている。

　これでユーザー登録の方法を覚えた。


メールの受信を、さくらインターネットへ移行


　メールサーバーを、さくらインターネットへの移行準備が整った。
　だが、慎重に物事を進めないと、失敗の原因になりかねない。

　そこで「suga2」という架空のIDを作成して、実際に、さくらインターネットのサーバーで
受信できるかどうか確認してみる。

　問題なく受信できた!!

　だった。


　次に会社の既存のメールサーバーに登録されているユーザー全てを
さくらインターネットにも登録する。この作業は

　めちゃ面倒な作業

　だった。
　でも、なんとか登録が終わった。


　さて、メールサーバーの移行だが、先に受信部分を移行させた後で
送信部分を移行させる形をとるため、2回分、設定変更が必要になる。

　そのため全社に対して

　2回にわけて設定変更を行います

　という通達を流した。

　さて、各人のメール受信の移行を開始する。
　本社の場合、すぐに変更ができるのだが、営業所の場合は手間がかかる。

　常時、パソコンの電源が付いていればリモートデスクトップという
遠隔操作を使えば良いのだが、

　そのため営業所の人に

　外出の際、パソコンをつけっぱなしにしてください!!

　と伝える事にした。

　この作業を1人、1人行っていった。
　全部終わらせるのに10日ぐらいかかった。


メール送信の移行作業

　前後は逆になったが、メールを受信を移行する前、送信部分の設定準備を行った。
　全て確認した上で、移行作業を行わないと、もし、途中で問題が発生しても戻すのが大変だからだ。

　メールの送信サーバーを、さくらインターネットに移行させるのだが、
メールの不正中継が発生しては具合が悪い。
　そのため、ホワイトリストの登録を行った。

ホワイトリストの登録
　
　既存のメールサーバーの場合、SMTP認証は行っていなかった。
　そのため不正中継される問題があった。

　さくらインターネットでは不正中継防止のため、初期設定はSMTP認証が必要になっている。
　だが、SMTP認証を行うと、認証設定の手間が出るなどして不便な場合も出てくる。

　そのためSMTP認証が不要のIPアドレスを設定する事も可能なのだ。
　それが・・・

　ホワイトリストの設定

　なのだ。


　ホワイトリストの設定だが、まずはサーバーコントロールの「サイトに関する設定」を見る。

サーバーコントロール画面のサイトに関する設定
「国外IPアドレスフィルター」を選択する。

　次の画面が出てくる。

サーバーコントロール画面の「ホワイトリスト接続許可設定」を選ぶ
水色で囲んだ「ホワイトリスト接続許可設定」を選ぶ

　すると、登録したいホワイトリストのIPアドレスとマスク数の入力画面が出てくる。

サーバーコントロール画面のホワイトリストのIPアドレスとマスク数の入力画面
ここで登録したいIPアドレスとマスク数を記入する。 うちの会社のグローバルIPアドレスとマスク数を登録した。 そして追加を押す。

　するとホワイトリストが登録された。

サーバーコントロール画面:ホワイトリストが登録された
ホワイトリストとして登録したIPアドレスとマスク数が表示される。 このIPアドレスとマスク数に該当するマシン以外は、SMTPサーバーへ接続する際 SMTP認証が必要になるのだ。

　非常に楽ちんな設定

　なのだ。

ルーターの設定変更

　送信メールサーバーの移行の前に、動作確認のため「suga2」というIDを使って、
さくらインターネットのSMTPサーバーを使ってメール送信を行ってみた。
　この時、メールソフトの設定は、SMTP認証は無しにしていた。

　SMTPサーバーへ接続できへん!!

　という問題が発生した。


　原因は、うちの会社のネットワーク形態に問題があった。
　インターネット接続のための回線はADSL回線を使っている。
　ADSL回線は非常に遅いという問題を抱えていた。

　そのためワイドVPNで接続している取引先(A社)を経由して
インターネットに出る形をとっていた。

A社経由でインターネット接続
ワイドVPNを使って、A社とうちの会社は回線接続している。 A社経由にした場合、うちの会社とA社は光回線で結ばれている上 A社は光回線でインターネット接続をしているから、 自社のADSLを使ってインターネット接続するよりかは 通信速度が速くなる。

　A社を経由してインターネット接続している上

　A社のIPアドレスをホワイトリストに入れていないため

　SMTPサーバーへ認証無しでは接続できへんかった!!

　ところで、この問題をどう解決するのか。
　話は簡単ではなかった。A社の場合、固定グローバルIPを持っていない。
　そのためホワイトリストの中に入れる事ができない。

　そこで思いついたのは

　SMTP接続のパケットはADSL回線にする

　だった。

　これによってSMTP認証無しでの接続ができるようになった。

　これのお陰で、社内システムのWeb申請システムなどで
Webに入力したデーターをPHPを使って、SMTPサーバーへ送信する場合
厄介なSMTP認証の設定が不要となるため、PHPのプログラムの変更が少なくて済む。

　だが、ADSL回線を使うため、メール送信の際、添付ファイルが重いとどうしようもない。

メールはSMTP認証を導入

　ADSL回線は遅いため、A社経由で、さくらインターネットのSMTPサーバーに接続し
メールを送信したい。

　そこでさくらインターネットのマニュアルを見る。
　各メールソフトごとのSMTP認証の方法が書いてあった。

　初めてのSMTP認証の設定。そのため・・・

　SMTP認証について何も知らへんかった!!

　だった。

thunderbirdでの設定
ポート番号は587を使う。 接続保護はSTARTTLSを使う。 ユーザー名だが、IDだけでなく「ID@XXX.sakura.ne.jp」といった形にする。

　そして・・・

　SMTP認証が成功

　だった。
　
　マニュアルの丸写しなので、驚く事もなければ、喜ぶ事でもないのだが
問題なく前に進んでいるので、ひと安心なのだ。


　そして各人のメールソフトで、送信メールサーバーの設定変更を行っていく。
　1人、1人の設定変更を行っていくため、10日ぐらいかかった。

送信メールが迷惑メールの判定

　SMTPサーバーを、さくらインターネットに移動させたのだが
少し困った問題が出た。

　SMTPサーバーを移行させたユーザーの場合、送信したメールが
相手先で迷惑メールに認定されやすくなった。

　実際、私自身のアカウントも、個人のHotmailに送信した際
迷惑メールに振り分けられた。

　原因はDNSの設定

　と推測した。


　この時点では、うちの会社にやってくるメールは
一度、社内のメールサーバーに到着した後、さくらインターネットへ転送している。

この時点での、うちの会社宛てに来るメールの経路
一度、うちの会社のメールサーバーに届くようにしているため DNSサーバーのMXレコードも、うちの会社のサーバーで設定している。

　そのためSMTPサーバーを、さくらインターネットのサーバーにしたユーザーの場合

　メールの発信元が、MXレコードと一致しない

　という現象が起こるのだ。
　そのため

　怪しいメール

　と判断されやすいと考えられた。

　だが、対策方法が思い浮かばないため、やむ得ないと考えた。
　なるべく早く切り替えができるように進めた。


DNSの切り替え

　ようやく全員のSMTPサーバーの設定変更が終わった。
　そして最後にDNSのMXレコードを書き換える。

XXXX.co.jp.	IN	MX	10	YYYY.sakura.ne.jp.

　ただ、DNSの情報を書き換えても、数時間から2日間は
既存のメールサーバーは停止できない。

　なぜなら、新しいDNSの情報が完全に伝わるまで、
古いDNS情報に基づいて、メールを配信するため
うちの会社の既存のメールサーバーを経由して、さくらインターネットへ
転送される形になるのだ。

　実際、DNSの情報を書き換えてから、2日間は、既存のメールサーバーを経由していたメールがあった。

　既存のメールサーバーのログで確認しながら、既存のメールサーバーを経由するメールが
なくなった事を確認した上で、既存のメールサーバーを停止した。


　これで無事、メールサーバーの移行が完了した。


最後に

　事前に問題点を洗い出し、移行作業の準備をしていたお陰で、大きな混乱もなかった。
　でも、あまりにも順調に行き過ぎて、感激はなかった。

　レンタルサーバーへ移行できたお陰で、システムの管理業務が減る。
　その反面、メールの配信に関する知識や技術が身につかなくなる。

　数年後、Postfixでメールサーバーを構築と言われても、構築する自信がなくなるかもしれない。
　複雑な心境に陥った感じだ。