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

2年ほど、ファーストサーバを使ってたんですが、だいぶ環境が古くなってきたことと個人的におもちゃのようにして使うという用途としては金額面で割安だったので、さくらVPS のほうに乗り換えました。

まだ、1週間ほどしか触れてないんですが、使ってみた第一印象をまとめてみました。

1年契約なら月額900円を切る料金プラン

とりあえず自宅でもLinuxサーバーに触れてあれこれ試してみたいって思っていたんですが、用途としてサービスを提供するとか、想定しているおもちゃ以上のことは今のところあんまり考えられなかったので、金額面で安い方がもちろん良いですし、個人でおもちゃのようにして使う分にはそれほどハイスペックなサーバーも必要無いという状況でした。

専用サーバーはかなり割高になってしまいますし、共有サーバーはroot権限がなかったり管理方法がかなり面倒なので、プログラム書いたりサーバー管理とかする上でのソフトウェアの設定の検証とか、その辺りのことをやりたいとなると、コストパフォーマンスでVPSプランにかなり分があります。

さくらVPSは月額980円で短月契約も出来るほか、1年契約をすれば月額900円を切る金額でroot権限つきというかなり自由度の高い環境を手に入れることが出来ます。

まだそんなに使い倒していない状況なので、安定性とかパフォーマンスというものを把握できていないのですが、先ほども書いたように個人的に自由に使えるLinux環境を手軽に手に入れたいという条件であれば、この金額はかなり魅力的ではないでしょうか。

自宅の古いPCをサーバーとして使うということでもいいんですけど、場所とったり保守どうすんだみたいなところもありますからね。。。

root権限付きで自由度の高い環境

VPSプランって大体root権限付いてたりしますけど、自由度ってそれだけじゃ決まらなかったりします。

まぁ、その自由度ってその環境でやりたいことの目的によるんですけど、自分はプログラムかいたりその中でもDBやApacheやらの設定弄ったりバージョン変えてみたりとやってみたかったりって思ってるんですけど、VPSの中ではユーザーの利便性をあげるために管理用のソフトウェアが提供されてたりするんですけど、そういうのが自分にとっては反って邪魔だったりもしました。

というのは、そういう管理ソフトウェアがPHPやらApacheやらのバージョンを握ってしまっていて、何でも出来るという環境ではなかったりするんですよね。

そういうのを無視して環境構成を変更することも出来るんですけど、サポートの対象外って扱いを受けたりもしますし、それをハックして外す手間って本来やりたかったことでもないので、あまりそこに時間かけたくも無いって思いもあったりするわけです。

yumコマンド使えるのにパッケージのインストールするのは、管理ソフトウェアを通してからしかインストールしちゃダメよ的なものもあったりしますからね。

さくらVPSも、管理ソフトウェアはあるんですけど自分の邪魔をしない程度の最小構成の機能ぐらいしか提供していなかったのでそれが都合よいかなという印象を受けました。

また、OSも幾つか選べる上に再インストールが簡単に行えるということも、魅力的に感じました。

環境変えて試してみるとか、新しいバージョンのOSを試してみたいって時にプランを変えることなく気軽に自分で対応できるのはかなり大きいのではないでしょうか。

とはいえ、手間のかかる環境でもある

自由度が極端に高いってことは、最初は何も無くてあとは自分たちでくみ上げていくって事だったりもしますので、本来自分がやりたいことをスタートさせるまでには少し時間がかかります。

レンタルサーバーって、どのプログラミング言語が入っているとか、このソフトウェアは利用可能とか、ある程度ユーザーが希望に沿っているようなことをプランの魅力の一つとして大々的に書いていたりしますけど、さくらVPSの場合OS選べますよとか基本スペックはこれぐらいですとかぐらいしか書かれてなくて、実際使ってみてもApacheもPHPも入ってなくてそれらを全て環境を一から構築していくことになります。

そういうのに時間をとられたくないって人にはあまりそぐわないかもしれません。

そういうのが楽しいとか、このソフトウェアはプレインストールされてるよと言われてもバージョンが固定されてたりもしますので、そこは自分の用途に合わせて自由にインストールできるようにしたいって要望を持っている人に向いているでしょう。

本当、最初にログインしたときには何も無さ過ぎてびっくりしたんですがね。

環境構築は一度してしまえばすむので、後の手間はそれほど他のプランとも変わりは無いと思います。

ただ、そういう知識が無いとか、環境を自分に合わせてカスタマイズした言って要望を持っているなら、それとは引き換えに時間をかける代償を受ける必要はありますので、それぞれ一長一短はあるかなと。

個人的には、ある程度くみ上げた段階で仮想マシンのバックアップ機能でもあって、いつでもその状態にリカバリできるような機能があればいいかなぁと思ったり。

まだ、自分の環境も完全にくみ上げていないという状況なので、もう少し使い倒して感じたことがあったらまとめてみたいと思います。

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

[PR]【早い者勝ち！】　.com／.net／.jp　ドメイン取るならお名前.com

[PR]So-netでauひかり！今なら20,000円キャッシュバックキャンペーン実施中！

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

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

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

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

サーバーを立てたらこれだけは見とけ！という25の項目

yumによるRPMパッケージの更新管理

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

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

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

サーバー管理で知っておきたいコマンドあれこれ。 - sysreport編 -

新しい技術とどう付き合い適用していくかって話

技術の移り変わりってものは激しいもので、数年も経てばそのとき最新だった技術はすっかり廃れたものへとなっていたりします。

大学のときにIT業界の流れって言うのはドッグイヤーだってたとえ話を聞きましたが、10年この業界に身をおいてみたら確かに入社当初の技術そのものって随分と変わってきています。

そうやって次々と生み出される技術そのものにエンジニアとしてどうやって付き合って、それを実際の現場にどのように適用していけばいいのでしょうか。

導入効果と現場での説明

新しい技術を導入する際には、それを導入することの効果ってものを算段して示しておく必要があります。

エンジニアのエゴとしてそれが面白そうだからという理由だけでは、反って開発現場に混乱を招くだけでなく、非効率な開発というものが行われてしまいます。

技術そのものの話としては、現在の最新のサービス基盤となるシステムであっても10年前の技術で少なくとも同等の機能は構築が出来たりもします。

まぁ、そこがコンサバ派のエンジニアの新しい技術への反感を招くところにもなったりするんでしょうけど、それを導入することでより効率的なシステム開発が行えるとか、ガラパゴス化したシステムを作るのではなく、業界標準への対応などの理由が出てきたりもするわけです。

ただ、新しい技術への対応というのは初期展開時に時間がかかったりもするので、小規模なシステム開発であればわざわざ新しい要素を組み込む必要も無かったりします。

今後の保守の対応への想定や、大規模システムでの工期短縮、新米エンジニアの技術習得の容易さ（その技術に慣れた後に関しての効率化とか）、現在の技術そのものが時代遅れになっておりメンテナンスされていない場合などへのセキュリティリスクへの対応などなど、導入することによって何が変わりどんな効果がもたらされるのかって事をはっきりさせておく必要があるでしょう。

新しい技術の導入効果って言うのは、なかなか定量的な効果として計測しにくいものもあったりします。

なんせ今の現場のスタンダードな開発手法などをそのまま適用しても開発が進められるところがあったりしますので。

そういったことをさらに現場で保守的な姿勢を取るエンジニアとか、さらに現場を長く離れている（もしくはまったく経験がない）上司へ説明しなければならなかったりもするのでなかなか骨が折れたりもする作業にはなります。

また、現在では外部に優れたサービスが安価に提供されている時代にもなっているので、それをわざわざ現場に導入することへの比較と効果も示しておく必要が出るかもしれません。

新技術に精通したエンジニアと教育

新しい技術を導入する際には、その技術に精通したエンジニアというものが必要になります。

これが流行っているんだぜ！ということで導入したものの皆手探りで開発をするということでは、効率化も何もありませんし、工期に余裕があればまだいいにしても大抵の開発の現場ではそんな余裕もありません。

そして、それが原因で品質の悪いシステムが出来上がり、リリース後に不具合が頻発しては自分たちの首を絞めることにもなりかねません。

そういったことを回避するためにも、その技術に精通してその技術に関して周りへの教育や使い方に関しての基本方針を決定することができるエンジニアが必要になってきます。

教育というのは思った以上に時間がとられたりもするので、1人だけではそこに手一杯になり、本業となる開発に専念することも出来なくなるケースもあります。

OSSの技術を持ってくる場合は、ドキュメントが充実していることやコミュニティが活発化していること、その技術のこれからのマイルストンがはっきりしているなども教育への影響上、重要になってきたりします。

例えば開発の効率化という名目で新しいフレームワークを導入したとしても、初めてそれに触れる人たちはその習得には1ヶ月ほど時間がかかったりしますので、ほぼ1ヶ月は本来のスケジュールほど開発作業が進まないことになったりもします。

教育がきちんといきわたっていない場合、想定しない使われ方をしたりして品質が低下したり、後半になって大きな手戻りを生んだりしてスケジュールを圧迫することにもなります。

そういったことを手厚くフォローするエンジニアが必要になってきますし、その役割を担う人が現場にどれだけいるかってところも技術を導入する際のキーとなってきたりします。

新しいプロジェクトでいきなり新技術を導入するって事をするよりは（案件によってはそうせざるを得ない場合もありますけど）、前もって新しい技術を検証する期間とそれを習得できるような教育方針を予め作っておくことも重要になってくるでしょう。

エンジニアの立場としては、常に何らかの案件でスケジュールを終われてたりもしますので、余裕を持って教育を受ける暇が無かったりはするんですけどね・・・。

なので、場合によってはその技術を持ったエンジニアを外部から招き入れることも検討が必要になってくるでしょう。

技術対象との相性

どんなにその新技術がすばらしいものであったとしても対象システムとの相性を見極めないと想定していた効果を得ることが出来なかったりもします。

先のフレームワークの話であっても、大規模システムの開発を効率化できるという効果があったとしても、適用する対象が小規模なものであった場合、そこでの作業は反って冗長なものを招いたりもします。

そういったものって開発手法が極めて統一化されているため制限事項も多いですし、教育期間を考えたら効果が出始める頃にはもう開発が終わっているよというものがあったりします。

また、最近のシステムではそれ単体で動くよりは、他のシステムと連携してというものが多かったりもするので、その技術が周りの環境にうまく適用できるかってところも見極めておく必要があるでしょう。

言語やOS、開発環境やクライアント環境などある特定の条件だとうまく動かない（またはサポートしない）というものもあったりしますので、適用する条件なども詳細に調査しておく必要性があります。

技術だけでなく、開発手法などを導入する場合でも開発現場だけでなく、主管となるクライアント側の業務そのものを変えてもらわないと効果が出ないという場合もありますので、総じて効果が出にくいという結果を生み出すことも考えられます。

クライアントにそんなことを強要するなと怒られるかもしれません。

そういった意味で、最初に書いた効果をはっきりさせておくとか、説明することでコミットメントを取り付けておくことが重要になってくるんでしょうけど。

こういったことに対しては、ある特定の綺麗に収まる範囲でまずは適用してみてその相性を見極めてみるというのも良いかもしれません。

自社内でやってみるとか、ある独立したシステムにだけ適用してみるとか。

ただし、無理に新しい技術を導入する事だけを優先するのではなく、まずはその準備として周りの状況を把握し、その周りから改善していくという必要も出てくるかもしれません。

まとめ

エンジニアの立場としては、日々生み出されたり進化している新しい技術への羨望というものは強かったりしますが、単にそれだけの自分のエゴで導入してみた場合、反って不利益をもたらしたりもします。

導入する目的や効果をはっきりさせ、それを導入した際の教育プランや適用範囲をはっきりと考えておくことがまず重要になってくるかなと思います。

自分としては、効果が出ることに関しては自明だったりもしますが、周りへうまく説明できなかったり理解が得られない場合は、導入することに関しては今一度検討する必要が出てくるかもしれません。

[PR]So-netでauひかり！今なら最大22,000円分プレゼント！

[PR]★ロリポップ！★WordPressやMovableTypeの簡単インストール、cron、共有SSL対応！

[PR]ホスティングサービス５０，０００社のビジネス利用の実績。

プログラマがプログラミング以外にしていること

正しいコードを書く作業、正しいコードを壊す作業

何でも屋であることの強みと危うさ

プログラミングが出来る人になるための熱意

内製化することの幻想と現実

何故プログラマーはシステムを作り直したくなるのか

トラブル時のシステムエンジニアと非システムエンジニアの焦りの違い

システム屋が非システム屋と話すときに留意すること

運用の中で崩壊していくシステム

社員が利用するソフトウェアは統一すべきか

プレッシャーを感じたら考えること

仕事も重要な役割やポジションを与えられると当然それがプレッシャーになってきたりもするわけで、こんなこと出来るのかとかうまく行く道筋が見えないといった場合でも、1つだけ考えることがあったりします。

それは、未来の自分の存在というイメージ。

要は今そこにある問題に潰されそうな自分とそれを何らかの対応をこなして（もしかしたらそれは失敗に終わるかもしれませんけど）プレッシャーから解放されている自分というものが確実にいるということです。

期限というものが存在するプレッシャー

何らかの役割を与えられ、解決すべき問題があり、それをうまく収めることを期待されているというような場合でも、その解決までには期限が与えられたりもします。

その期限がプレッシャーになったりもするんですが、逆に言えばその期限までしかプレッシャーがかかりません。

ダメならダメで別の問題が浮上してそれに対してプレッシャーが・・・、ということはあるかもしれませんが最悪な方向に歩もうとする人はいないでしょうから、何らかの解決法というのはそれまでに生み出して解決もしくは緩和していく必要が出てきます。

プレッシャーを跳ね除ける一つの手段は問題を分割することで、そこにかかるプレッシャーも分散化していくのも有効だろうと思うわけです。

プレッシャーが与えられる状況というのは何らかの不安要素がそこにあるわけで、それが何なのか分析することでどこに不安を感じているかもわかりますし、それを解決するためにどうすればいいのかってところにも焦点を与えることが出来るようになります。

その先々のことをいくら考えても仕方がありません。

最悪の事態というのはいくらでも考えられますが、今起きていないことをあれこれ考えたところで手のうちようが無いわけで、それは起きたときに考えればいいでしょうし、そこで新しく生まれるプレッシャーもその際に受け止めればいいだろうと思います。

私の場合、エンジニアやってますのでシステム開発なんかで常々「無事にリリースできるだろうか」という不安を持ったりもしますけど、その先の「リリースした後に大規模トラブルが起きたらどうしよう」なんて不安は考えても仕方が無いことであり、まずは想定しているタスクや期中に起こった課題をクリアして無事にリリース日を迎えることだけを考えるようにしています。

そもそもトラブル起す前提で開発を進めたりはしませんし、起きたとしたらそれを解決するためのプレッシャーは与えられますけど、それはそれで別のマイルストンとして対応すべき問題なのだろうと思うわけです。