サーバーレンタルする際に考慮したいサーバー管理ツールによる差異

「レンタルサーバーをさくらVPSに乗り換えてみました」に書いたように、今年からさくらVPSを個人の趣味としての環境に利用しています。

以前はファーストサーバを使ってたりしてたんですが、値段やサービス以外で幾つか自分の思うようなことが出来ないといったことがあり乗り換えました。

サーバーをレンタルする上で、その利用シーンに合わせて幾つか比較するポイントがあります。

今回はその1つである、付属するサーバー管理ツールについて書いてみます。

高度なサーバー管理ツールを備えた環境で気をつけたいポイント

ファーストサーバのVPSプランの方は管理ツールとしてPlesk が標準で利用可能になっています。

- Pleskコントロールパネル

運用していく中では、こういった高機能な管理ツールがあったほうが楽な場合もありますが、開発してたりするとそれが邪魔になってくることもしばしばあります。

例えば

・ Apacheの設定変更が制限される

・パッケージのアップデートも管理ツールと依存関係があったりする場合はNGになる

・パッケージのインストールやアップデートも基本的に管理ツール経由で行う

・プログラミングの観点でも管理ツールによってApacheの設定が握られている関係で対応しにくい部分がある

というようなものです。

まず、レンタルサーバーで提供されているサーバー管理ツールは、Web上で動作するのでApacheの設定が管理ツール側に握られていることがあります。

Apacheの設定は出来なくも無いですが、設定変更するとサーバー管理ツールが動作しなくなったり、サポートの対象外になるということもあります。

また、設定も管理ツールを動作させるために設定ファイル自体がラッピングされて別ファイルとして定義されていたりして、非常に変更が面倒になっていたりもします。（そもそも変更すること自体を許可していないので触れるなって事かもしれませんけど）

Plesk自体もApacheの設定ファイルが標準的な場所（/etc/httpdなど）以外に存在して、実質その別の場所にある設定ファイルでApacheが動作しています。

Apacheの設定が握られていることで、その環境でプログラミングをしようとするとやたらと制限事項が多いこともでてきます。

以前に書いた「ファーストサーバVPS環境でPHPのセーフモードを回避する」もその1つです。

Apacheのログの取り方を変えたり、VirtualHostの設定を変えるということを設定ファイルを直接書き換えて出来なかったりします。

ただ、これらはサーバー管理ツールを通して簡単に設定変更が出来たりして、設定ファイルを直接いじることが出来ないという人には親切かもしれません。
要は設定変更したいなら管理ツールを通してやりなさい、そのために必要な機能は提供するよ（でも、出来ない設定もあるよ）ってスタンスになっています。

プログラミングを本気でしたい！って人には不向きな環境かもしれません。

また、サーバー管理ツールが高度な故にその使い方がわかりづらかったりもします。

マニュアルが提供されていたりはしますが、それを一から読んで覚えるのは大変ですよね。

環境のスタートアップだけでも結構体力を使うことになったり。

Web上で一通りのことが出来たりするので、例えばFTPの設定をせずに管理ツール側でその機能が提供されていたり、ドメインの設定の追加が容易に出来たりするといったことは、この環境ならではのメリットでしょう。

そのほかに、サーバー管理ツールが利用しているパッケージも管理ツールに握られてバージョンアップや削除が出来なかったりします。

例えば、Apacheや管理ツールでPHPやPerlの動作設定ができるのであれば、そのパッケージ自体もバージョンを上げるということが制限されたりもします。

サーバー管理ツールのバージョンをあげることで対応できる部分もありますが、例えばPHPのメジャーバージョンアップをしたいとかといった場合に、どうにも身動きが取れないという状況にもなったりします。

基本機能のみを提供するサーバー管理ツールを提供する環境で気をつけたいポイント

お次は逆に、そういった高度な管理ツールが提供されておらず、ごく基本機能のサーバー管理ツールが提供されている環境です。

現在利用しているさくらVPS環境とかはこちらにあたります。

さくらVPSも、サーバー管理ツールが無いわけではありません。

Web上から幾つかの基本操作が行える管理ツールが存在します。

ただし、（仮想）サーバーの起動/停止やサーバーの負荷の状況を確認したりといった基本機能のみしか提供されていません。

- さくらVPSコントロールパネル

この環境だと専用サーバーを使っているかのように色々自由度の高い管理が行えます。

もちろんApacheの設定も自在です。

ただし、その自由度ゆえに逆に自分たちで色々と管理する事項が増えてきます。

・サーバー管理をするための知識が必要

・ バックアップ自体も自前で実装

・どうしようもなくなった場合にはOS再インストール

といった感じのことです。

サーバー管理するための知識自体は、VPS環境を利用したいのであればある程度普段からサーバー管理をしていて身に着けているというよう状況でないとつらいかもしれません。

バックアップ自体をサーバー管理ツールが提供してくれるものがあったりしますが、そういった機能がない管理ツールを利用している場合は、バックアップ機能自体を自前で実装する必要があります。

プログラミング環境として使う場合は、外部のバージョン管理のリポジトリを利用したりすれバックアップを兼ねることも出来たりしますが、サービスをその上で提供したい場合は多くのコンテンツを取り扱うため、丸ごと環境をバックアップしておく機能があったりしたほうが管理は楽です。

また、リカバリ自体も自分でやる必要が出てきます。

OSの再インストールなどは仮想環境ということもあって、簡単に切り替えることができる機能が用意されていたりもしますけど、その上のデータはもちろん全て初期化されるわけで、リカバリプランを自前で立てておく必要はあるでしょう。

何れも自前で何でもやろうぜ！ってのが基本スタンスになっていたりして、それはそれで自由度が高く何でもできるメリットはあるわけですが、一方で運用していると面倒に感じてくることも多々出てくるかもしれません。

まとめ

それぞれに一長一短があったりするわけですが、遊びでもガリガリとプログラミングをしたいといった場合は、あまり高度なサーバー管理ツールを備えたレンタルサーバーは選ばない方が制約無く利用できます。

一方で、何かサービスをすぐに提供するということを考えている場合は、運用を楽にしてくれる高度な機能を兼ね備えたツールがある方のプランを選択した方がよいかもしれません。

安い専用サーバープランのようにも見えたりして、root権限付きとか書いているとそこで何でもできるかのように思えたりもするのですが、同じようなVPSプランでも実際に中身をよく見てみると出来ること、出来ないことが結構出てくるので注意が必要です。

[PR]レンタルサーバの決定版ファーストサーバ

[PR]SSLサーバ証明書なら[ドメインキーパー]◆VeriSign/GlobalSign/他取り扱い

[PR]格安固定IPが【５分で発行】＋【初期無料】＋【２ヶ月無料体験】

[お名前.com] サービスを構築するまでに行ったサーバー設定作業もろもろ

レンタルサーバーをさくらVPSに乗り換えてみました

レンタルサーバーのファーストサーバ設定あれこれ

ファーストサーバVPS環境でPHPのセーフモードを回避する

ファーストサーバでPEARを使う

ファーストサーバでPostgreSQLを利用可能にする

ものすごい数のアタックを受けているようなのでその際のユーザー名を晒す

ftpやscp不要でターミナルエミュレータを通してファイル転送ができるlrzszパッケージ

クライアントからサーバーにファイル転送をする際に、FTPやSCPのコマンドが利用できなかったり、ネットワークやポートの制限がかかっていて転送できないというような場合があります。

その他にも、踏み台サーバーを経由してアクセスしないといけないなど、直接ファイル転送するのが著しく面倒だったりする環境もあったりします。

そういったときに、lrzszパッケージを利用すればターミナルエミュレータを通してファイルを転送することが出来ます。

これは、TeraTermなどクライアントのターミナル環境を通してつないでいるまさにそのサーバーにファイルを転送したり、そこにあるファイルを受信したりすることができます。

rzコマンドを通してサーバーへファイルを転送する

まず最初に、lrzszパッケージがサーバー上に存在しない場合は、yumコマンドなどを通してインストールしておきましょう。

# yum install lrzsz
- snip -
Installed:
lrzsz.x86_64 0:0.12.20-22.1
Complete!

これだけで準備が整いましたので、早速ファイルを送信してみましょう。

送信したいサーバー上でrzコマンドを実行し、ファイルの転送待ち受け状態にします。

# rz
rz waiting to receive.**B0100000023be50

次に、クライアント環境のターミナルエミュレータ（今回の例ではTeraTerm）からファイルを送信してみます。

転送方法は、「ファイル」→「転送」→「ZMODEM」→「送信」メニューを選択します。

すると、送信したいファイルを選択するダイアログが開きますので、該当のファイルを選択します。

これだけでファイルの転送が完了しています。

rzコマンドを実行したディレクトリを見てみると、送信したファイルがあるはずです。

# ls
hoge.jpg

ちなみに、ZMODEMはバイナリ転送用のプロトコルでその他にもXMODEMやYMODEMが存在しており、lrzszパッケージでもそれぞれに対応した、rxコマンド（XMODEM用）、rbコマンド（YMODEM用）、rzコマンド（ZMODEM用）が存在します。

ただし、ファイル転送効率などはZMODEが一番優れており、その他のプロトコルを使うメリットはほとんど無いかと思います。

szコマンドを通してサーバーからファイルを受信する

続いて、先ほどと逆のサーバー上にあるファイルをクライアントに転送（ダウンロード）する方法です。

サーバーからファイルを転送する場合は、szコマンドを転送したいファイル名を引数にして実行します。

# sz hoge.txt

受信方法は、先ほどファイルを送信した場合にあったZMODEMの受信メニューから行います。

ファイルはターミナルエミュレータを実行しているフォルダ（TeraTermの場合はC:\Program Files\teratermとか）に保存されます。

複数のファイル転送はできなかったり（といっても、予めファイルをzipやtarで固めておけばおおかた済んだりしますけど）、そのサーバーまで端末がつながっているという前提条件がありますけど、ファイル転送用のコマンドやネットワーク的に制限があったりする場合にすぐにファイルをアップロード・ダウンロードができて便利に使えます。

Linux上でファイルを削除してしまった際にさっくり復活できるextundelete

対話型のコマンドを自動化できるexpectコマンド

[SSH] 公開鍵認証方式で接続する

ちょっとセキュアないつものFTP設定

OS上にいないバーチャルユーザーを使ってFTP接続する

FTPのアクティブモードとパッシブモード＋ vsftpdでの設定方法

[vsftpd] 特定の拡張子のファイルのアップロードを禁止する

[Linux] 削除できないファイルの作り方

inotifyを使ってファイルやディレクトリに起きたイベントを簡単に監視する

[24時間365日] サーバ/インフラを支える技術

エンジニアを育てるということへのジレンマ

私が勤めだした頃の情報システム部門は非常に小さな組織で、ミッションも漠然としており（というか、当時は右も左もわからなかったのでそこはちゃんと上司が明確なミッションを持って取り組んでいたかと思いますが）、ただひたすらにシステム開発というのに専念できる組織でした。

そこには小さな組織ながら、エンジニアとしての仕事の楽しみというものを感じられる環境でしたし、組織自体もエンジニアを育てていこうという目的を感じられる場所でした。

時は流れて、現在は当時に比べたら非常に大きな組織となっていて、与えられるミッションも厳密になってきており、何よりも不景気のあおりもあってか情報システム部門の運営に関わる大きなコストというものに、会社としても懸念を示すようになっています。

こういった状況だと人を育てることさえもなかなか難しい環境となります。

エンジニアの端くれとして仕事をしている自分にとっては、こういった環境で仕事をするエンジニアの立場というのは憂慮すべきことだと感じたりします。

情報システム部門におけるエンジニアの立ち位置

組織が小さな頃というのは非常に多くの内製のプロジェクトをこなしており、自分たちの能力がそのプロジェクトに直結するような仕事が中心でした。

しかし、変革のスピードが求められたりそもそも自分たちに無いノウハウを導入するためには、外注してSIerへ委託するなど、外部のリソースを利用することが多くあったりします。

これは、企業内のIT活用が促進され、業務との結びつきが必然となったりと時代の変革により、エンジニア自体の業務形態も変わっていたことも理由としてあるかと思います。

しかし、こうした業務形態の変化により情報システム部門としてのエンジニアの立ち位置や役割というものも大きく変わってきたりしています。

外部のリソースを活用することが中心になってくると、どうしても情報システム部内でやっていく業務といえば要件定義や外部設計など上流工程が中心になってきます。

それはエンジニアの仕事ではないとは言いませんが、本来システムの動作や仕様について事細かに把握するためには実際にそのシステムを作り運用していくというのが一番だと思いますが、そういった業務を経験するメンバーが減ってくると、エンジニアとしての基礎能力というのは低下の一途を辿っていきます。

ひいては情報システム部門自体のエンジニアとしてのスキル能力も低下することになってしまいます。

で、こういったことをいうと大抵お偉い方は「もっと頭を使うより高度な仕事をやって欲しい」と言ってきたりもするのですが、あまりその高度な仕事をするコンサルタントのような人は周りで見かけたことは無かったりもして、より懐疑的にもなったり。

そもそもエンジニアの数倍もする単価でそういった人を雇い入れては、プロジェクトを掘り起こし計画化しては断念しての繰り返しをしていたりするのを横目で見てて、こんな仕事をすればよいのか！なんて思えるはずもなかったり。

閑話休題。

要は今やエンジニアのエンジニアとしての仕事というものをこなしつつも、組織としてのニーズを満たすための能力も身に着けていかなくてはなりません。

昔は、技術だけを中心において注力できた仕事が、うまく立ち振る舞うための様々な角度の能力が必要になってきたりしていると思います。

それが、ある程度の経験を経てのことであれば当然よいかと思いますが、入社間もないエンジニアにも同様の事が求められていくと基礎能力が定着する前に変に上辺だけの知識を持った人しか育てられなくなってきますし、何よりもエンジニア自身のキャリアパスも描けません。

イニシャルコストより気になるランニングコスト

内製化が好まれなくなったのはそのスピード感やノウハウ以外に、運用フェーズでのランニングコストの大きさが気になるからというのもあったりします。

外部に委託するのと同等の能力が社内にあると仮定すれば、イニシャルコストだけで見れば内製化をした方が断然安く抑えられたりもします。

これは、主に人件費を中心に置いた場合の話ですが、その他のメリットとしてもコミュニケーションが円滑に取れ、プロジェクトの路線変更にも柔軟に対応ができ、そこで得たノウハウを定着することも出来たりするわけです。

しかし、その安いイニシャルコストよりもシステムのライフサイクルを見た場合の長期的なランニングコストを見て判断を渋られたりもします。

規模が大きくなるに比例して多くのエンジニアを雇い入れる必要がありますし、内製することによりそのエンジニアをその後も抱え込む必要があります。

これは、組織の運営コストとして大きなリスクになると捉えられたりもしますし、情報システム部門など社内の開発業務を中心におくと、仕事にも波が出るためその案件が終わった後の話がどうしても気になったりもします。

もちろん、仕事など自分たちでいくらでも生み出せたりもするわけですが、情報システム部門の場合はそれが会社として利益を生むような仕事でもなかったりするため、多くのエンジニアを抱え込むのはどうしてもマイナスの要素に見られがちです。

組織の一員になったエンジニアは、その後のキャリアを生み出せる土壌を作る必要がありますし、教育も重ねていく必要が出てくるでしょう。

そういったコストもランニングコストの中には含まれたりします。

なので、大きな案件を対応する場合にスポットでエンジニアを雇い入れたりして対応することになったりしますが、そういった人たちは社内のリソースではないため、そもそもスキルレベルが上がったりノウハウが蓄積することにはなったりしません。

運用後に大きなトラブルや改修を加える場合に、再度そういった人たちを雇ったり外注するのを見れば、果たしてランニングでも総合的に見てコストが抑えられるのかは疑問に持ったりもするのですが、そういったのは不確定な要素でもあり、明確にわかる教育コストと比較するとどうしても前者の方が選択されがちだったりもします。