さくらのレンタルサーバの環境設定

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の６日目の記事です。
　
今回はさくらのレンタルサーバの環境設定について説明します。

準備する環境

さくらのレンタルサーバではスタンダード以上のプランからシェルログインが利用できます。 その為Composerをはじめとして必要であればgitの利用も可能です。
　
今回は今後の記事で利用するComposerが利用できる環境を準備したいと思います。
記事中では契約ユーザー名が表示される部分を｢(ユーザー名)｣又は｢(username)｣と置き換えて表記しております。
　
｢アンインストール用シェル関数の登録｣についての説明を削除(アンインストール手順は別手順を記載済み)

① シェルをbashへ変更

さくらのレンタルサーバでは初期状態ではシェルはcshとなっています。

% echo $SHELL
/bin/csh

私は普段使い慣れているbashに設定しますが、その他にも利用可能なものはありますので自分の好みで設定してもよいでしょう。

■bashのパスの確認

% which bash
/usr/local/bin/bash

■利用可能なシェルの確認

% cat /etc/shells
# $FreeBSD: release/9.1.0/etc/shells 59717 2000-04-27 21:58:46Z ache $
#
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/sh
/bin/csh
/bin/tcsh
/usr/local/bin/zsh
/usr/local/bin/rzsh
/usr/bin/passwd
/usr/local/bin/bash
/usr/local/bin/rbash

　
シェルの変更は｢chsh｣コマンドで行います。

% chsh -s /usr/local/bin/bash
Password:
chsh: user information updated

変更の際はパスワードの入力を求められますのでサーバパスワードを入力します。

合わせて｢.bash_profile｣と｢.bashrc｣も作成しましょう。 予め両ファイルを作成しその後必要な部分のみ編集します。

% touch .bash_profile
% touch .bashrc

次に｢.bash_profile｣を編集します。

vi .bash_profile

記載内容は次の通りです。

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

現時点では特に記載すべきものはありませんので｢.bashrc｣が存在した場合の読み込みのみ記述します。 作業完了後再ログインし設定したシェルの環境に切り替わっている事を確認してください。
　

② binディレクトリの作成

｢.profile｣を確認するとわかりますが、さくらのレンタルサーバではユーザーのホームディレクトリ配下の｢bin｣ディレクトリに予めパスが通っています。
しかし該当のディレクトリは存在しない為、ディレクトリを作成しこのディレクトリに実行ファイルのインストールを行いたいと思います。

[(username)@www ~/bin]$ mkdir ~/bin

③ ｢php.ini｣ファイルの編集

次に｢php.ini｣ファイルを編集します。
Composerを利用する際次のようなエラーがでる場合があります。

The "https://packagist.org/packages.json" file could not be downloaded: SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Failed to enable crypto
failed to open stream: operation failed
https://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date

このエラーに対応する為に予めcurlで使用する証明書を取得し使用するように設定します。 予めファイルの保存先(｢ssl｣ディレクトリ)を作成し、そこに証明書をダウンロードし保存します。

[(username)@www ~/bin]$ mkdir ~/ssl
[(username)@www ~/bin]$ wget http://curl.haxx.se/ca/cacert.pem

次にさくらのレンタルサーバのコントロールパネルから｢php.ini｣の設定を編集します。
コントロールパネルにログイン後、メニュー内の｢PHP設定の編集｣を選択し、次の内容を記載します。

curl.cainfo=/home/(username)/ssl/cacert.pem
openssl.cafile=/home/(username)/ssl/cacert.pem

記載後｢保存する｣をクリックし編集は終了です。 なお、本操作後は｢/home/(ユーザー名)/www/php.ini｣にファイルが作成されています。
　
なお、私はこの問題の解消に以下のサイトを参考にしました。

qiita.com 　
　
合わせてコントロールパネルからPHPのバージョンも設定します。
さくらのレンタルサーバでは2015年12月6日現在デフォルトの設定では｢PHP 5.4.45 (cgi-fcgi) (built: Oct 19 2015 11:02:31)｣が設定されています。なお、さくらのレンタルサーバではその他に｢4.4｣｢5.2｣｢5.3｣｢5.4｣｢5.6｣が選択可能ですのでここでは｢5.6｣に変更しておきましょう。
リストから｢5.6｣を選択して｢変更｣ボタンをクリックして変更は完了です。
　
コントロールパネルでの操作を終えた後｢.bash_profile｣に｢PHPRC｣の設定を追加します。

PHPRC=/home/levelnine/www/php.ini
export PHPRC

上記の設定を行う事で先ほど設定した証明書の設定がコマンドラインからの実行時にも正常に読み込まれるようになります。
　
以上で作業は終了となります。
　

④ Composerの導入

準備は整いましたのでComposerの導入を行います。
Composerの導入そのものはご存じのとおりのコマンドを実行するだけですので、インストール先ディレクトリに移動し実行します。

[(username)@www ~/bin]$ cd ~/bin
[(username)@www ~/bin]$ curl -sS https://getcomposer.org/installer | php
#!/usr/bin/env php
All settings correct for using Composer
Downloading...

Composer successfully installed to: /home/(username)/bin/composer.phar
Use it: php composer.phar

インストールそのものは以上で完了です。

私はリンクを張り利用しますがここは好みでよいかと思います。

[(username)@www ~/bin]$ ln -s composer.phar composer

念のため動作確認もかねてバージョン確認を行います。

[(username)@www ~/bin]$ composer --version
Composer version 1.0-dev (feefd51565bb8ead38e355b9e501685b5254d0d5) 2015-12-03 16:17:58

正常にバージョンが取得できました。
　

⑤ ライブラリ導入先ディレクトリの作成

最後にライブラリの導入先ディレクトリを作成します。
今回はユーザーのホームディレクトリ直下に作成していますが、例えばアプリケーション毎に管理する場合はアプリケーションディレクトリ内に作成するといいでしょう。

[(username)@www ~/bin]$ mkdir ~/lib

今後Composerを利用してパッケージの導入を行う場合はこのディレクトリに移動し操作を行います。
以上で現状必要となる環境設定は完了です。

Composerの使い方

最後にComposerの使い方を簡単に説明します。

① パッケージのインストール

多くのサイトでは｢composer.json｣を編集してパッケージを導入する方法を紹介していますが私は多くの場合コマンドラインから直接導入を行います。
例えば｢monolog｣を導入する場合は次のように行います。

[(username)@www ~/bin]$ composer require monolog/monolog

｢require｣オプション付きで実行する事で合わせて｢composer.json｣にも追加されています。 バージョンを指定しない場合は最新のバージョンが導入されますが、もしバージョンも指定したい場合はパッケージ名の後にコロンを追加しその後にバージョン番号を指定します。

[(username)@www ~/bin]$ composer require 'monolog/monolog:1.17'

② パッケージのアンインストール

｢remove｣を実行する際に｢--update-with-dependencies｣オプションを指定します。
このオプションの指定により依存するパッケージも合わせて削除されます。

[(username)@www ~/bin]$ composer remove monolog/monolog --update-with-dependencies

③ プログラムからパッケージを利用する

実際に導入したパッケージをプログラムから利用する場合、プログラム内で｢vendor/autoload.php｣を呼び出します。

<?php

require 'vendor/autoload.php';

※パスは省略してありますので適切に指定してください
　

　
以上でさくらのレンタルサーバでの環境設定は終了です。
その他にも幾つか便利に使う為の設定はありますので機会があれば紹介したいと思います。

明日からは昨日紹介したライブラリを個々の紹介したいと思います。

PHPでの開発におけるライブラリやツールの選択

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の５日目の記事です。
　
今回はPHPでの開発におけるライブラリやツールの選択について考えたいと思います。

企画担当者が担当する「開発」とは？

さて一言で「開発」と言っても、規模だけでも小規模なものから大規模なもの、そして構成で言っても単純なものから複雑なものまで様々なです。
単純なもので言えば単体機能を有するツールの開発もあれば、会社サイトの問い合わせフォームの実装、もう少し複雑になるのであれば認証機能を持つデータ管理アプリケーションであったり、場合によってはちょっとしたポータルサイトのようなものまで開発する事になるかもしれません。
さらに言えば、昨今ではPC向けサイトよりもスマートフォン向けサイトやコンテンツの対応も増え、場合によってはそのバックエンドの開発のような事も行う事がないとは言えません。
　 以前はCakePHPを中心として開発を進めていましたが、やはり規模の小さい単純な案件ではもっとシンプルに進められないかという気持ちが強くなり、結果今ではマイクロフレームワークを中心とした構成に変更しました。
これから紹介する記事ではそのマイクロフレームワークを中心とした構成で私が利用するものをご紹介していきたいと考えています。

私が利用するライブラリやツールのご紹介

それでは具体的に紹介していきたいと思います。

① Slim（フレームワーク）

Slim Framework

Slimフレームワークは非常にシンプルで且つ拡張性も有するマイクロフレームワークです。
フレームワークに求めるものは人それぞれだと思いますが、私はルーティングに関する機能、リクエストに関する機能、レスポンス及びビューに関する機能、そして拡張性を持たせる意味でフック処理やそれに類する機能があれば十分だと考えています。その視点から見るとSlimフレームワークは非常に最適で十分なフレームワークであると感じました。

② Twig（テンプレートエンジン）

Homepage - Twig - The flexible, fast, and secure PHP template engine

PHPでテンプレートエンジンというと一般的にはSmartyにたどり着きます。実はそれほど拘りはなくむしろ私自身もともとフレームワークを利用する前はSmartyをベースにした自前の構成で開発をしていました。しかしSmartyは日々進化を続けテンプレートエンジンという役割から少し逸脱したレベルまで到達しているようにも思えます。その為、連携しての利用を考えるとそれなりにバージョンを管理する必要もあり、また、場合によってはバージョン依存の問題を解消する為の時間を割く必要も増えてきました。
このあたりのやり取りにつかれ、現在は消去法的にTwigにたどり着いています。もともとSlimを利用する事を先に決めていましたので、そこから関連する情報の多さも考慮してテンプレートエンジンにはTwigを選択しました。

③ Illuminate Database（データベースコンポーネント）

illuminate/database · GitHub

最近ですとIdiormあたりも人気ですが、あえてIlluminateを選択しています。とはいえ選択に至る切っ掛けは少し本質的な部分から外れてしまっており、もともとは認証ライブラリとしてSentinelの採用を想定しており、その中でIlluminateの利用も視野に入ってきた為、機能的に不足は感じなかったのでIlluminateを採用しました。Illuminate自体はLaravelのコンポーネントですので、例えばある程度の規模の開発を行うとなった場合にフレームワークをLaravelにするという場合にもスキルは生かせるのではないかと考えています。

④ Sentry（認証管理ライブラリ）

cartalyst/sentry · GitHub

一番悩んだものがSentryです。理由としては既に後継のSentinelがリリースされておりSentryはDEPRECATEDとなっており利用を推奨していない状況だからです。実装だけを考えますとSentinelでも問題はないのですが、使ってみた感じではSentryの場合は重複登録時のエラー処理や認証エラーの原因が例外として個別に捕捉できますが、Sentinelでは単純にエラーとしかわからず結果その部分を補う必要があります。それほどの負担ではないもののちょっとこの部分私の理解が進むまでは当面Sentryを利用した方が良いのではないかと考え、現状は認証管理についてはSentryを利用する事としています。

⑤ Respect Validation（バリデーションライブラリ）

Respect\Validation

Respect Validationは使いやすさと機能の多さの両面からおすすめのバリデーションライブラリです。マイクロフレームワークの場合、簡易的な検査であればフレームワーク側で実装されているものもありますが、フルスタックフレームワーク同等のレベルの機能を使いたいと思った場合は個別でライブラリを導入する必要があります。
Respect Validationは直感的に使えますのでそれほど躓く事なく利用する事ができると思います。

⑥ PHPMailer（メール送信ライブラリ）

PHPMailer/PHPMailer · GitHub

PHPMailerは非常に有名なライブラリですので説明するまでもありませんね。私は元々Qdmailが優れたライブラリであった為長く愛用していましたが、メンテナンスが長いこと行われていない状況が続いていました。利用する分には大きな影響はないのですがPHPのアップデートも行われることもあり切り替えを行う事としました。メール送信という処理は比較的頻度が高く実装する為、切り替えるとなるといろいろ迷いましたが、結果的にPHPMailerが最もしっくりきたので選択しました。
もしかすると他にももっとよいライブラリがあるのかも知れませんが、現時点では不満もなく活用できています。

以上が主に利用するライブラリとなります。

なお、その他ログライブラリもありますが、ログについては条件により実装方法がかなり異なる（ローカルで単純に出力する場合もあれば、外部サービスへ出力する場合もあるなど）ので、今回のおすすめからは除外しております。機会があればケースを整理してご紹介できればと思います。

次回からはまずはレンタルサーバ上での環境の整備についてご紹介した後、それぞれのライブラリの利用についてご紹介したいと思います。

さくらのレンタルサーバで独自ドメインを利用している場合に発生する問題

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の４日目の記事です。
　
今回は前回少しだけ触れましたさくらのレンタルサーバを利用する際に注意すべき独自ドメインの設定に関する問題について取り上げます。

一般的なコンテンツの公開（新規・サーバ移転）の流れ

まずはじめにコンテンツを公開する際に行う、ドメインの取得からコンテンツが公開されるまでの流れを説明します。 この流れは新たにドメインを取得し新しいコンテンツを公開するケース（以降、新規と表現）と、既に公開済みのコンテンツを公開に利用するレンタルサーバのみを変更するケース（サーバ移転）の二つが存在します。

① 新規のケース

新規のケースでは、ドメインの取得から始まりサーバの契約及びその設定、そして公開するコンテンツの配置やその設定を行い、その後DNSサーバにて公開時に利用するサーバの情報をDNSレコードとして登録し、その情報が伝播する事で順次ユーザーにコンテンツが閲覧する事ができる状態となります。
（便宜上、検索エンジンへの登録やURLの配布などの手順は省略します）
　
　
新規の場合はそもそも公開済みのコンテンツがありませんので、今回問題とするケースは発生しません。

② サーバ移転のケース

一方でサーバ移転のケースでは新規の場合と異なり、既に掲載中のコンテンツがありますので公開中のコンテンツに影響を可能な限り与えずに移設を完了する必要があります。
想定される一般的な流れとしては、まずは移設先のレンタルサーバの契約を行い、契約した移設先のレンタルサーバ上でコンテンツを公開する為の設定を行います。その後、移設するコンテンツのアップロードやプログラムが正常に動作する事に確認を行い、最終的にDNSサーバにてレコードを書き換えその情報が伝播する事で順次ユーザーが移設後のサーバに訪れるようになります。
　
　
移転先のサーバへのアクセスは移転作業担当者の端末上でhostsファイルの変更を行うなどして該当ドメインのアクセス先サーバを移転先サーバに行われるよう一時的に変更する事でレコードの書き換えを行わずに独自ドメインでのアクセスと同等のコンテンツの表示確認やプログラムやスクリプトの動作確認を行う事が可能です。
　
このように、サーバ移転を行う場合はあらかじめ移転先のサーバにて準備を行い移転先で正常に表示が行われることやプログラムが含まれる場合は仕様の変更などによりその影響が出ていないか等を確認し正常に動作する事が確認でき次第、DNSレコードの書き換えを行い移転先となるレンタルサーバにアクセスが行われるよう手続きを進める必要があります。

さくらのレンタルサーバに移転する場合の流れ

前述のようにサーバ移転のケースではDNSのレコードの書き換えはあくまでも最後に行う作業となるのですが、さくらのレンタルサーバで独自ドメインを行う場合に限りこの流れでは対応する事ができません。
　
さくらのレンタルサーバでは独自ドメインを利用する場合は、あらかじめレンタルサーバにその設定を行う必要があります。その際、利用するドメインのAレコードが対象となるさくらのレンタルサーバに設定されていないと手続きを進めることができません。
その為、さくらのレンタルサーバに移転する場合はサーバの準備を行う段階でDNSの書き換えを行い、その後サーバの設定、コンテンツのアップロードという流れになります。 なお、コンテンツのアップロードと表示確認そのものは、独自ドメイン経由のアクセスにこだわらない（プログラムやスクリプトが影響を受けない）のであれば標準で割り当てられるさくらのドメインにて行う事で最低限の確認は行う事が可能ですので、それを考慮した場合さくらのレンタルサーバへの移転は次にような流れになります。

このようにさくらのレンタルサーバでは独自ドメインを利用する為にはあらかじめDNS側でレコードの設定を変更しておく必要がありますので、短縮する事はできるものの、他社で行うような移転先サーバ上であらかじめコンテンツの表示確認やプログラムやスクリプトの動作確認を行った上で移転の実施を行う事ができず、どうしても多少のトラブルが発生する事を想定しなければなりません。
　
確かに単純な会社サイトや影響の限定的なコンテンツであればあらかじめ移転のお知らせを掲載し、利用者に影響がある事を告知すれば良いのかもしれませんが、そういったことを行う事は当然としても、やはり移転作業はより安全に行いたいと思うのが担当者の本音であると思います。
　

なぜさくらインターネットではこういうことになったのか

そもそもこの問題が発生したのは、2012年にさくらインターネットで起きたサブドメインハイジャック問題のタイミングであったと認識しています。
　
もともとさくらのレンタルサーバはさくら自身で運用しているDNSサーバと密接な連携が行われており、何れかのさくらの提供するサービスとドメインの結びつける事で他のサービスにもその設定の影響が及ぶ問題がありました。
この関係だけでなく、DNSサービスの問題も重なって結果的には第三者によりサブドメインをハイジャック可能となる脆弱性が生じることとなりました。
　
www.sakura.ad.jp
　
この問題を解消する過程で仕様の変更が行われたのですが、その際に予めDNSサーバへの操作権限がある（つまりドメインの所有権を有する）事を確認する為の措置として、事前にDNS上でレコードの設定を行った場合のみ独自ドメインに関する設定ができるような仕様に変更されました。
　
個人的な意見を述べるのであれば、そもそもレンタルサーバを含むマネジメントシステムの機能側の仕様を変更する話が本来の対応のあるべき姿であったと思うのですが、おそらくはその部分の変更を行うとなると提供しているサービスに大きな影響を及ぼす事が想定された為、結果、利便性を損なう事が想定されても現状のような対応とする事を選択したものと思われます。

少しでも影響を軽減する為に

独自ドメインの利用に関する問題点について説明しましたが、それだけですと何ら解決になりませんので、可能な限り影響を最小限にする為のテクニックを共有したいと思います。

① DNSのレコードを書き換える前にTTLの値は最少の値に変更する

そもそもさくらのレンタルサーバの利用に係らず、レコードの変更を伴う作業の場合はあらかじめ一時的にTTLの値を最小の値に変更しておきましょう。
キャッシュDNSでは原則としてTTLで指定された期限を経過し有効期限切れとなったキャッシュに対する参照が行われた場合、その応答を行う為に権威DNSへ紹介を行う事になります。その結果、該当ドメインの権威DNSで設定された内容がキャッシュDNSにも反映される事となり結果的に反映の時間を短縮できる可能性が高まります。
なお、残念ながら設定された値で必ずしも伝播が行われるわけではなく、一部のキャッシュDNSではTTLの値に従わないものがあったり、またそもそもTTLの値を変更してもその値の変更を参照し反映する為には既に設定されているTTLで指定された期限が経過している必要がありますので、少なくとも短縮を行う事ができる、程度の理解でいる方がよいでしょう。

② 独自ドメインの追加及び設定を行った後は一端レコードを移転前のサーバに戻す

前述したようにさくらのレンタルサーバに独自ドメインに関する設定の際に行われているのはドメインの所有権の確認です。
その為、一端設定を終えてしまえば特にその後DNSに設定した内容に影響されることはありません。
ですので、例えば移転を予定するサイトのログからユーザーが訪れない時間を予め確認しておき、①のように事前にTTLを最少の値にした状態で一端レコードを移設先のサーバ（つまり、さくらのレンタルサーバ）に変更します。
その状態で概ねTTLの時間が経過した頃にレンタルサーバの設定画面から独自ドメインの追加とそれに関連する設定を行います。
そして設定が完了したら速やかにレコードの設定内容を移設元のサーバに戻すことで他社のレンタルサーバと同様にhostsファイルを変更するなどの設定により移設先のサーバに担当者のみが接続できるようにできます。

さくらのレンタルサーバが参照するDNSは恐らく内部で準備しているキャッシュDNSであり、これは適切な値を権威DNSから取得し運用されていると考えられますので、TTLで指定した値に限りなく近い期限で設定した内容が伝播していることが想定されます。

以上の２つの手続きを行う事でさくらのレンタルサーバへの移転であってもサービスやコンテンツの公開にそれ程影響を及ぼすことなく移転作業を進める事が可能となります。

同一サーバに対しワイルドカードで設定されたドメインはどうなるの？

さて、さくらインターネットでサブドメインハイジャックの脆弱性が存在していた問題を取り上げましたが、レンタルサーバの仕組み上、例えばワイルドカードをあるサーバに対して設定した場合レンタルサーバ側ではどのアカウントが該当ドメインの所有者か判断して処理をおこなっているのでしょうか？
　
例えばコアサーバーではサーバを指定してアカウントを開設する事が可能ですので極論を言えば、同一サーバ上で運用されているドメインに対して悪意のある攻撃を仕掛ける事が可能となります。
　
Aさんは自分のアカウント上で｢example.com｣ドメインの｢aaa｣サブドメインと｢bbb｣サブドメインを運用する為にDNSのレコードの書き換えを行いました。その際ワイルドカードで設定したとします。
その設定を知った第三者であるBさんが同一サーバのアカウントを取得し｢example.com｣ドメインの｢ccc｣サブドメインに関する設定を自分のアカウント上で行ったとします。そうするとどのような挙動となるでしょうか。
　
答えは｢ccc｣サブドメインはAさんの意図しないまま、Bさんのアカウント上で設定された内容で表示されます。

これは仕組みを考えると止むを得ない事なのですが、そもそもレンタルサーバ上の各ドメインの受け入れはバーチャルホスト機能を利用して行われている事が一般的です。その為、仮に第三者のアカウント上であっても同一サーバに対して設定さえ行ってしまえば、仕組み上サーバとしてはアクセスがあった場合、該当のバーチャルホストに設定された内容で表示するしかありません。
　
但し、少なくともコアサーバーであればこの問題は事前に予防する事が可能です。
コアサーバーでは独自ドメインに対する設定が行われる場合、サブドメインのみの設定の場合はその他のアカウントの設定内容とのチェックが行われませんが、独自ドメインそのものが既に他のアカウントに設定されている場合、その独自ドメインに対するサブドメインをそのアカウント以外に設定する事はできません。
その為、正当なドメインの所有者（前述の例であればAさん）が最初にドメイン設定を行う際に実際に使用するものがサブドメインであっても、ドメインそのものの設定を行っておけば第三者がそのドメインに対する設定を行う事を防止する事が可能となります。
　
もっともサブドメインのみでの運用というのはかなりレアなケースなのですが、例えばブログのみ運用しておりそれを｢blog.example.com｣のように設定している場合、もしかするとそれ以外のサブドメインを第三者が設定し自分の意図しないコンテンツを公開されてしまうおそれがあります。 またもっと深刻なケースでは、場合によってはクッキーの仕様を悪用し、クッキーを使い管理しているサービスのセッションを乗っ取るような行為が行われる可能性もあります。
　
レアなケースではありますが、そのような事も起きる事がありますのでワイルドカードの設定は行わない、そして、使用するかしないかに係らずサブドメイン以外についてもとりあえず設定しておくという癖をつけると万が一という事の予防になるかもしれません。

まとめ

さくらのレンタルサーバで独自ドメインを利用するケースで、他社のレンタルサーバから移転する場合は少し癖があります。
対策はありますので落ち着いて準備し、手順を踏めばサービスへの影響は最小限にすることが可能ですので是非参考にしてみてください。
　
また、レンタルサーバにはさくらのレンタルサーバにあるような癖がそれぞれのレンタルサーバに存在しています。
全てをここで上げる事は難しいのですが、ご紹介したようなコアサーバーの癖のようなものもありますので利用する場合の設定は最小限の設定で第三者に悪用されないよう適切な設定と確認を行うようにしていただければと思います。
　
明日からはPHPでの開発におけるライブラリやツールの紹介に入りたいと思います。

おすすめのレンタルサーバのご紹介

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の３日目の記事です。
　
前回は昨今のレンタルサーバ事情とレンタルサーバの積極的な利用について説明しました。
今回は実際に私がおすすめするレンタルサーバについておすすめする理由と利用上の注意などをお話したいと思います。

おすすめのレンタルサーバ

まず、結論からお伝えすると現時点で私がおすすめするレンタルサーバは｢さくらのレンタルサーバ（スタンダードプラン）｣と｢コアサーバー（CORE-A）｣の二つです。
　
もともとは｢さくらのレンタルサーバ（スタンダードプラン）｣をおすすめに選んでいたのですが、2015年10月1日よりコアサーバー及びバリューサーバーでもさくらのレンタルサーバ同様にSNIを用いた独自ドメイン環境のでSSL証明書の利用が無料で提供されるようになりました。
これによりさくらのレンタルサーバに優位性のあった部分が失われ、一方でさくらのレンタルサーバには幾つかの致命的な問題も抱えている事情もあり、暫くの間いろいろと比較してみたのですが何れかに決定するだけの要素は見いだせず、その結果｢さくらのレンタルサーバ（スタンダードプラン）｣と｢コアサーバー（CORE-A）｣の何れかをそれぞれの特徴を確認し選んでご利用いただくという事が適切であると判断しました。
　
なお、想定する利用シーンとしては例えば会社サイトを作成しお問合わせフォームを準備したり、また取引先との間で簡単なデータをやり取りするアプリケーションを構築したり、部門内で利用する簡単な業務アプリケーションのような比較的軽微なアプリケーションの設置を含むものを想定しており、それ以上の規模や条件(例えば取り扱いが難しいデータの利活用や共有サーバでは処理しきれない負荷のプログラムの実行等)の場合は、VPSやクラウドサーバを利用すべきと判断しますので、あくまでもその前提でのお勧めという意味で読んでいただけると幸いです。

各サービスの比較

まず両サービスとその他のサービスを機能面から比較します。

(1) 独自ドメインの利用に関する比較

サービス名	プラン	マルチ　 ドメイン 対応	ドメイン 利用数	メール　　 アカウント
さくらのレンタルサーバ	スタンダード	○	20個	無制限
コアサーバー	CORE-A	○	無制限	無制限
エックスサーバー	X10	○	無制限	無制限
ロリポップ	スタンダード	○	100個	無制限

さくらのレンタルサーバでは利用可能ドメイン数が20個に制限されています。
１アカウントで複数のドメインを取り扱うようなケースではデメリットとなりますが、通常の利用においてはそれほど制限とはならないでしょう。

但し、独自ドメイン環境下でのメールアカウントについてはさくらのレンタルサーバのみ特殊な制限があります。
さくらのレンタルサーバでは作成するメールアカウント名はサーバ上で共通したものとなります。その為、例えば｢orepedia.com｣ドメインと｢orepedia.net｣ドメインの両方を何れも同じアカウント上で管理しており、例えば｢example｣というメールアカウントを作成する場合、それぞれのドメイン毎のメールアカウントとして作成する事はできません。
その為、メール受信時には｢example@orepedia.com｣と｢example@orepedia.net｣は同じメールボックスにて管理される為利用時には注意が必要となります。

(2) 独自ドメイン環境下でのSSL証明書の利用に関する比較

サービス名	プラン	SNI対応	証明書の持込 及び持出	利用料金
さくらのレンタルサーバ	スタンダード	○	○	0円
コアサーバー	CORE-A	○	○	0円
エックスサーバー	X10	○	×	0円
ロリポップ	スタンダード	−	−	−

さくらのレンタルサーバとコアサーバーについては何れもSNIを利用した独自ドメイン毎のSSL証明書の利用を無料で提供しています。
一方で、エックスサーバーについてはSNIを利用した独自ドメイン毎のSSL証明書の利用を無料で提供していますが、利用できる証明書は同社のサービス内で取得したものに限られます。
ロリポップに関してはSNIを利用した独自ドメイン毎のSSL証明書の利用に対応していません。

(3) アプリケーション実行環境に関する比較

サービス名	プラン	MySQL	SQLite	PHP	Ruby	Python
さくらのレンタルサーバ	スタンダード	20個	○	○	○	○
コアサーバー	CORE-A	無制限	○	○	○	○
エックスサーバー	X10	50個	×	○	×	×
ロリポップ	スタンダード	30個	○	○	○	○

エックスサーバを除くと基本的に横並びの状態です。
データベースの作成数に差はありますが、そもそもレンタルサーバ上で利用する程度のデータベースですので20個でも通常は十分であると思われます。
おそらくデータベース数の作成数の制限をうけるような状況の場合、負荷制限（データベースへの同時接続制限等）の方が深刻である事が予想されますので、サービスやサイト毎に別契約とするか、またはレンタルサーバではなくVPSやクラウドサーバを選択する必要があると考えるべきでしょう。

(4) 利用料金に関する比較

サービス名	プラン	初期費用	単月	1年契約	2年間累計
さくらのレンタルサーバ	スタンダード	1,029円	515円	5,142円	11,313円
コアサーバー	CORE-A	0円	515円	5,142円	10,284円
エックスサーバー	X10	3,240円	1,080円	12,960円	29,160円
ロリポップ	スタンダード	1,620円	648円	6,480円	14,580円

※全て税込(8%)の表記に統一
※エックスサーバーは3ヶ月単位の契約

利用料金についてはエックスサーバーを除くとそれ程変わらないことがわかります。
その為機能面の差異で選択すればそれほど問題にはならない事がわかります。

コアサーバの問題（なぜコアサーバー一択ではないのか）

ここまでの比較を見るとコアサーバーの条件がもっとも優れておりさくらのレンタルサーバが対抗馬になる余地はありません。価格的にも機能的にも微妙にコアサーバーがすぐれている点は明らかですので。

しかしコアサーバーにも幾つかの欠点があります。
　
一つは同居しているユーザーによりプログラムの応答やデータベースの挙動に影響が出る点。これは回避策はあるもののいわゆる地雷鯖と呼ばれるものが比較的多く存在する為外れを引くと特定の時間帯になるとエラーが続発することとなります。私はサービス開始時点からずっとコアサーバーを利用しており３回程サーバ移転をしつつ利用してきましたが、地雷鯖にあたると22時頃を中心に全うに動的コンテンツを表示する事は出来ないほどの状況に陥りました。
但し、最近では当時ほどの地雷の話を聞くこともなくなりましたのである程度収まっているのかもしれませんが、そういった可能性があるという事はマイナスポイントの一つです。
なお、この話は他のレンタルサーバでも同様で当然さくらのレンタルサーバでも同様の問題に遭遇する事もありますが、コアサーバー程致命的な状況に陥る事は少ないようです。
　
もう一つは午前4時前後のサーバの状態が常に不安定になる事です。
その時間帯の重要性はさほど高くはないかもしれませんが、この現象は私が利用したサーバの全てで起きていましたのでコアサーバーの共通する問題(現象)のようで回避する方法はありません。
具体的には同時間帯になると動的コンテンツの表示ができなかったり、またSSH経由の接続ができない、管理コンソールに接続できないなどおそらくはサーバ側で何か決まった処理が動いているらしくその時間帯は必ず不安定な状況に陥ります。その為、一応24時間サービスを提供する前提であるウェブコンテンツの器としての評価は若干下がるという点は否めません。
　
そして最後は比較的大きな仕様の変更(良いものも含む)が比較的頻繁に行われる(行われた)という点です。
前述の通り私はXREAから始まりコアサーバーサービスが開始されてから今日までずっと契約をし利用してきました。この間サーバの仕様変更は数回行われ環境設定の方法の変更やプログラム実行環境の変更等幾つか動作に影響を与える規模の変更も行われました。
変更そのものはどのようなレンタルサーバでも起きうることですが、もう一つ付け加えるならば警備なバージョンアップ作業の際も結構な頻度でバージョンアップエラーの影響で動的コンテンツが動作しないという状況にも陥ります。このあたりはサーバーの仕様や運用体制等の影響もあるのでしょうが、ちょっと不安定さを感じるというのが本音です。
　
もっとも、値段と提供するサービスを考えればこの程度の欠点は十分許容範囲内で目くじらを立てるほどの問題ではありません。ですのでコアサーバー自体も十分魅力的でコスト的にも機能的にも選択して損の無いサーバである事に変わりはありません。

さくらのレンタルサーバーのメリット

一方でさくらのレンタルサーバーにはオンリーワンといえる機能がいくつかあります。
　
一つはリソースブースト機能です。
この機能は例えばプレスリリースの発信やメディアでの紹介などにより一時的にトラフィックやトラフィックの増加に伴うサーバ負荷が高まった際に、サーバ側での動作制限を一時的に緩和し処理可能な状態としてくれるオプション機能です。
連続的に利用する事はできませんのであくまでも一時凌ぎではありますが、一般的にはそういったトラフィックは継続的なものではありませんので十分効果的な機能であるといえます。
　
もう一つはWAF（ウェブアプリケーションファイアウォール）機能です。
この機能はシグネチャ検査・セッション管理などの検査を実施し、それらをもとに攻撃にあたると判断したアクセスを遮断を自動的に遮断してくれるものです。
利用可否の判断は若干複雑でコンテンツやドメインの利用状況にも左右されるのですがこういった機能が提供されるという事はメリットの一つであると言えます。
　
最後に国外IPアドレスフィルタも紹介します。
基本的に多くのウェブサイトへの攻撃は海外経由で行われます。その為、動的コンテンツを提供する場合の多くは必要ない場合は海外からのアクセスを最初から遮断してしまう事も少なくありません。
この機能はそういった設定を簡単な操作で有効にすることができ、海外IPアドレスからのアクセスをブロックする事ができる機能です。手動で設定を準備し行う事も当然可能なのですが、アドレスリストの管理も含め自動的に行えることはやはりメリットの一つであると考える事ができます。
　
なお機能面ではありませんが個人的な意見として添えるなら、さくらインターネットのユーザーサポートに対しては私は好印象を持っています。
解決できない問題（仕様の為、という回答）も比較的多いのは否めませんが、メールサポートやチャットサポートだけでなく電話でもサポートを受け付けコミュニケーションが図れるという点は特にビジネスでの利用ではメリットであると言えます。
もしもサポートにもある程度の質を要求するのであればこの点は評価に含めて検討してもよいかもしれません。

このようにさくらのレンタルサーバにはオンリーワンというえる機能が毎年増えていることもあり、そういった意味で多少のサービスの差異程度であれば候補から除外する必要はないレベルのサービスです。

そんなさくらのレンタルサーバにも致命的な欠陥がある

さてそんなさくらのレンタルサーバですが、致命的ともいえる欠点があります。
　
まず一つは独自ドメインに関する設定がDNSの設定後でなければ行えないという点です。
ある意味ウェブサーバとしては致命的すぎるのでなぜこの問題を放置し続けるのか理解はできないのですが、この問題がある為に本格的に公開・運用しているコンテンツをさくらのレンタルサーバーに移転させ際は一時的にコンテンツを停止せざる得ない状況に陥ります。 この問題は別の記事でもう少し詳しく説明しますが、他社と比較してこの点は大きく減点されるのは避けられません。
　
もう一つはSNIを用いたSSLの実装が微妙であるという点です。
単体で利用する場合は回避方法もあるのですが、例えばCDNサービスと連携する場合のようにSSL経由のアクセスを外部と連携して提供する場合は比較的致命的な問題も発生します。
もっとも実際にこの問題が発生するのは特定の条件でのみとなりますので大きな減点とまでは言えませんが、SSLの利用は今後重要性を増す事を考えるとその環境が特殊であるという点は減点対象にはなるでしょう。
　
このようにメリットも多いさくらのレンタルサーバですが、それと同じぐらいデメリットもあるというのが現実です。

まとめ

このようなこともあり、結局のところ｢さくらのレンタルサーバ（スタンダードプラン）｣と｢コアサーバー（CORE-A）｣の二つはそれぞれの特徴を理解してどちらが自分に合っているか判断する事が重要です。　
若干煮え切らない答えではありますが、もしもレンタルサーバを利用してみようと思われた方はいずれかのサーバを候補にしてみてはいかがでしょうか。　
　
さて次回の４日目は本記事でも触れたさくらのレンタルサーバで発生する独自ドメイン利用時に発生する問題について少し詳しく説明したいと思います。

昨今のレンタルサーバ事情とその選び方

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の２日目の記事です。
　
今回は新しい企画の立上げ時には事実上必須となるレンタルサーバの選択についての記事です。 　
新しい企画を立上げいざサービスを開始するとなると少なくともホームページの準備は必要となります。ネットサービスやインターネット経由で注文の受付やサービス間の連携を行う場合もそうですが、それ以外の場合でも会社サイトの公開やブログの運営など様々な場面でレンタルサーバを利用する事となります。
昨今では格安で利用する事ができ、昔ほどレンタルサーバの選択に慎重さが求められなくなりましたが、やはり各社それぞれ特徴があり、その特徴を理解して選択する事は非常に重要です。
　
今回はそんなレンタルサーバについての昨今のレンタルサーバの事情を確認しつつその選び方について共有します。

なぜこの時代に｢レンタルサーバ｣を選ぶのか

ここ数年でインターネットで提供されるサーバインフラは目覚ましい進歩を遂げ、VPSやクラウドのサービスが増えただけでなく、AWSのようなより実践的な機能を多数有し年々進化を続けるサービスまで非常に多岐にわたるものが登場しています。
またVPSやクラウドサーバの単価も下がり、以前は海外サービスでしか提供されていなかったレベルのものが国内事業者からもワンコインで当然のように提供されるようになりました。
　
この結果、レンタルサーバを利用するのかそれともVPSやクラウドサーバを利用するのかという判断基準は曖昧になり、ある程度インフラ構築の経験を持ってしまうと安易にVPSやクラウドサーバを選択するという事も少なくありません。
しかし近年レンタルサーバも目覚ましい進化を遂げており結果大抵の要求はレンタルサーバ環境で実現する事が可能になりました。
　
プログラミング言語の利用やデータベースの利用が可能であることは当然として、その他にはどのようなメリットがあるのでしょうか。まずはその点のご紹介から始めたいと思います。

(1) 独自ドメインの利用と独自SSLの利用が誰でも可能になりました

従来のサービスではレンタルサーバでは共有SSLのみが提供され独自ドメインを持ち込んだ場合は、多くの場合で独自SSLオプションのようなサービスを追加し有料で利用する事が必要でした。 またその際も自由な認証機関や証明書の種類を選べるわけではなく、国内大手のもののみ利用可能であるケースであった場合、月数百円程度のレンタルサーバに対して独自SSLオプションとサーバ証明書の発行手数料だけで年間数万円という高額な負担が必要となる矛盾した状況がありました。
　
しかし近年では｢SNI SSL｣に対応したレンタルサーバが急速に増え、主要レンタルサーバサービスの多くでSNIベースのSSLを安価に利用する事ができるようになりました。
　

www.sakura.ad.jp

www.xserver.ne.jp

www.coreserver.jp

www.value-server.com

このような事情から独自ドメインでサイトを構築する場合に、お問合わせフォームを独自ドメイン環境下でのSSL化対応する為だけにあえて安価なVPSやクラウドサーバを選択する必要性はなくなりました。

(2) シェルログインの解放とComposerの普及

以前からシェルログインは幾つかのレンタルサーバサービスでは解放されており目新しいものではありません。
一方でそれらの機能を用いて行う事はそれほどなく、結果的にレンタルサーバの選定においてシェルログインの可否は要素としてそれほど重要性をもつものではありませんでした。
しかし近年各言語においてパッケージ管理ツールが広く普及し、PHPにおいてもComposerが近年急激に普及するとレンタルサーバにおけるシェルログインの重要性は一気に高まりました。
　
もともと安価なVPSと同等の金額のレンタルサーバではサーバの処理能力としての評価は難しく、環境の自由度はVPSが高く一方で状況によっては処理性能はレンタルサーバの方が高いというケースもありました。
但しサービスの継続的提供を考えた場合、レンタルサーバ環境ではライブラリの管理等の問題もあり現実的には選択し辛い現実もありましたがComposerの普及とシェルログイン可能な環境の提供の組み合わせによりそれらの課題もかなり解決できるようになりました。
　
結果比較的単純なサービスの提供だけであればシェルログイン機能が利用できるレンタルサーバ上でComposerを使いライブラリのインストールを行う事ができる環境が整った現状では安価なVPSサーバをあえて選択するケースは依然よりも少なくなったと判断できるかと思います。

(3) 周辺サービスの拡充

前述の通りレンタルサーバはここ数年で飛躍的な進歩を遂げ、安価なVPSと比較しても十分に対抗サービスとして選択できるレベルに達していると実感していますが、それをより現実的なものとしたのは周辺サービスの拡充です。
　
そもそもレンタルサーバはあくまでも共有環境という制約がある為高トラフィックを処理するのには限界がありました。しかし近年ではCloudFrontやCloudflareのように安価(条件によっては無料で)に利用できるCDNが登場しそれらの問題を解決できる場合も増えてきました。
CDNサービスを上手に利用する事でレンタルサーバでは処理しきれない程の高トラフィックであっても柔軟に対応する事ができ、トラフィック対策の為だけにクラウドサーバ上での構築を行うような負担は回避する事ができるようになりました。
　
その他にも例えばレンタルサーバで課題となるがメール送信環境の問題です。
共有サーバという性質上サービス自体がそれほど複雑でなく基本的な要件としてはレンタルサーバで十分満たせていたとしても、メール送信環境場合によってはメールをトリガーとした機能の整備を行うが為に専用のサーバを準備しなければならないという事も少なくありませんでしたが、しかしこれらも近年では周辺のサービスで全て個別に解決する事が可能です。
　
例えば、小規模なポータルサイトやSNSサービスを構築する場合であれば会員登録時には多くの場合メールでのやり取りが発生します。このメールを迷惑メールとして処理されたくないという課題を解決したいのであればメール配信サービスを利用することで多くの場合で解決する事が可能です。また送信ではなく受信時に特定の処理を行いたい場合でも同様で、近年提供されているメール配信サービスでは受信時に特定の処理を呼び出す為のインターフェースが実装されており簡単にそれらの処理を実装する事が可能です。
なお、あえて付け加えるならば多くのメール配信サービスでは月間の送信件数が一定以下であれば無料または非常に安価に利用できるケースが多いためプロトタイプの開発やアルファ・ベータサービスの提供程度であればそれらのプランで対応する事も可能です。
　
このようにもしも一部の機能がレンタルサーバでは賄えないと思った場合も安易にVPSやクラウドサーバの導入を検討せず、まずは部分的な専用サービスの利用を検討し段階的に環境を拡張する事でも十分対応することが可能です。

(4) 自由度と運用負担のトレードオフ

もしも１日のうち多くの時間をインフラ環境のチューニングや監視、管理に割くことができるのであればそれは素晴らしい事です。
しかし現実では必ずしもそのような望ましい環境ばかりとは限りません。その一方でVPSやクラウドサーバを利用する場合、時間の有無に係らず一定の作業時間をその管理に割り当てる必要が生じます。
　
レンタルサーバと比較した場合のVPSやクラウドサーバの最大のメリットはその自由度であると言えます。一方で最大のデメリットは運用負担となるでしょう。 しかし前述の通り、近年のレンタルサーバやそれを取り巻く環境の進化は著しくある一定の規模や仕組みのサービスであればレンタルサーバでも十分にサービスを提供する事は可能です。
　
これから立ち上げるサービスや事業で求められる環境に高い自由度が必要なのであれば迷わずVPSやクラウドサーバの利用を前提に準備を進めるべきですが、もしもそうでない場合、まずはレンタルサーバでの提供を視野に入れる事ができれば運用開始後に担当者として行うべき運用負担のうち、基盤部分の管理についてはあなたに代わってレンタルサーバ提供会社が十分な対応を行ってくれるでしょう。
　
重大なセキュリティインシデントへの対応、ライブラリのバージョンアップ、ハードウェアの管理、そして新たなトレンドに対応した機能の提供等レンタルサーバを選択する事により得られるメリットは多岐にわたります。
　
そしてあなた自身の時間が空くという事はその時間をサービスそのものの企画や開発に充てる事ができ、それはサービスの価値を高める事にもつながるのではないでしょうか。

まとめ

以前は｢安いけどちょっと物足りない｣というイメージのレンタルサーバでしたが、昨今のレンタルサーバは基本機能だけでなく、付加機能も非常に充実しており安価なVPSよりもよほど利便性が高いと言えます。
特に企画担当者のようなサービスの立上だけでなく様々な作業の一つとしてインフラの準備やサービスの開発・運用を行うようなケースではコンパクトに機能が集約されており、複雑なインストール作業や設定作業を行わなくても直ぐに準備作業に取り掛かれるレンタルサーバは上手に付き合う事で強い味方となる存在です。
　
今までは最低でもVPSという選択を行われていた方もこの機会に一度レンタルサーバの活用について検討いただき、機会があれば是非一度実際に活用していただき、進化したレンタルサーバを実感していただければと思います。
　
３日目は実際に提供されているレンタルサーバサービスの選択について具体的なサービス名を挙げて紹介したいと思います。

ある企画部門に属する担当者の役割とミッション

この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の1日目の記事です。

はじめに

このAdventCalendarで想定する企画担当者とは、基本的にはITエンジニアが企画者兼技術者となるようなケースを想定しており、その為大手ネット企業に勤める企画担当者というケースではなく、中小企業や創業間もないITベンチャーであったり、場合によっては社内に技術部隊を抱えないような企業を想定しています。
　
こういった環境ではITエンジニアの日々の活動もプログラミングやインフラ構築や運用のような技術的なものではなく、どちらかというと普段はパワーポイントやエクセル、ワード等を用いた提案書の作成や提供中サービスの営業・営業支援であったりと日常的にスキルを深めるような活動が行えない一方で、一度新しい企画を立ち上げるとなると｢エンジニア｣という肩書があるがために初期段階で多大な作業を抱える事が少なくありません。
　
今回の一連に記事ではそういった環境に身を置く同じ境遇の企画担当者(兼ITエンジニア)の方に向けて私が最近活用しているサービスであったり環境を備忘録を兼ねて整理しつつご紹介したいと思います。

この連載で想定される企画担当者(兼ITエンジニア)に求められるもの

大手ネット企業の企画担当者とは違い、この連載で想定される企画担当者とはある意味フルスタックエンジニアに近いものが想定されます。 但し、本来のフルスタックエンジニアとは違いこの場合は成り行き上そのような状況に追い込まれているケースが多く、時間的にも予算的にも選択肢がなく、結果個人のスキルや経験でなんとか乗り越えている状況であるといえます。
その為、サーバの準備からプロトタイプの作成、場合によっては本サービスの開発から当面の運用まで幅広く関与する事が求められます。
　
ここまでであれば一般的なエンジニアとそれほど違いはないかもしれませんが、企画担当者(兼ITエンジニア)の場合、そのサービスそのものを運営する会社の設立であったり、場合によってはその会社の日常的な業務の一部も対応する必要などが求められ、サービスの開発や運用といった技術的な対応だけでなくある意味総務部門的な役割もこなす事が求められる事もあります。
　
この様に、特定の分野や技術に特化して企画の立案や開発に関与するというよりも、企画の立案からサービスインまで幅広い領域で実務的に動く事がある意味この連載で想定される企画担当者(兼ITエンジニア)のミッションであると言えます。

連載で取り扱う内容について

連載では、小規模なサービスの提供を想定した最も安価で手軽な環境の準備から始まり、サービス開発で利用するライブラリ、ツール、サービスの紹介、そして開発したサービスを運用する会社を立ち上げる事となった場合に利用できるサービスなどを紹介していきます。
前項で定義したようなリソース的に制約のある環境下で少しでも効率よく企画に応じた開発や環境の準備を行う事を目的とし、それらに役立つであろう内容を紹介していくことを目標としています。
　
序盤の記事ではベースとなるインフラの紹介としてレンタルサーバの違いと特徴について説明します。
もはやワンコインで利用できるレンタルサーバですが、地味な部分で各社それぞれに違いがあります。その点をよく理解しサービスを選択する事は非常に重要です。昨今では安価にVPSの利用も可能となりましたが、時間的制約のある企画担当者にとってあえてレンタルサーバを選択するメリットについても確認します。

中盤にかけてはPHPでの開発におけるライブラリやツールの紹介を行います。
一般的なITエンジニアと違い技術習得にさける時間には限りがあるだけでなく、一つ一つの開発ではそれほど多くの時間をさくこともできません。
ここではプロトタイプの開発を想定した場合、共通的に利用できるライブラリを導入から基本的な利用まで紹介していきます。

終盤では技術的な話題ではありませんが、万が一あなたが会社の立ち上げに関わった場合に利用できるサービスについて紹介します。
例えばバーチャルオフィスサービスはもはや一般的なものとなりましたが、利用する上で注意が必要な事もいくつかあります。そられについて私が実際に使っている（使っていた）サービスを中心にご紹介しつつ、私が過去に経験した問題点も共有できればと思います。

最後に

備忘録も兼ねている為、一人アドベントカレンダーという形での執筆ですので少し気軽に書き始めています。
そもそも内容が２５日分も現時点ではなく（現状１５日分程度の計算）、途中息切れ（ネタ切れ）も予想されますので、その点ご容赦いただければと思います。

GMO mBaaS(Backendless)の評価

GMOがBaasの提供に参画するようです。
　

GMOインターネット、バックエンドサービス「GMO mBaaS powered by backendless」β版を公開〜モバイルアプリの開発コストを大幅に削減〜 - GMOインターネット株式会社

　
私はこれまで仕事でいくつかのモバイルバックエンドサービスを試してきました。 例えば『monaca』であったり、最近ですと『nifty mobile backend』であったりですね。 当然、『Parse』のような海外の代表的なサービスも評価しましたが、やはり国内サービスは企画段階から相談もしやすく扱いやすいという事で主に国内サービスを主軸に進めています。 　
現在、多くの場合で企画や開発中のサービスでの利用（またはその前提）は『nifty mobile backend 』の利用を前提にして準備・作業を行ってきました。 理由としては、環境が整っている事が１つと、コスト面で比較的柔軟性が有ったためです。
　
特にgithubに開設されたユーザーフォーラムの存在はそれまで手探りで課題と向き合っていた技術者にとっては非常にありがたいもので、私も常にウォッチしていました。
　
しかし、『nifty mobile backend』の利用者には既に運営より告知が行われていますが、春のサービスリニューアルに合わせて、提供プランの見直しが行われる見込みです。 　
多くの部分では機能強化となっており、利用者として非常にありがたいものの、サービスプランとしては中間となる『Pro（月額 2,000円）』が３月３１日の申し込みを持って受付を終了する事となりました。 おそらく、それほどの利用者はいなかったための判断だと思うのですが、個人的には中間プランの廃止はランニングコストに直結するので結構悲しいお知らせとなりました。 　

月額2,000円というのは、個人開発者でも負担はそれほど重いものでもないので、私は存続を強く希望します。但し、そもそもnifty社の方向性としてはクラウドサービス全般に言えますが、法人向けソリューションを強化しているという事情も分かりますので、止むを得ないのかなと。

　
そのような事情もあって、GMO社からの発表についてはなかなか興味深い発表でしたので、早速ベータテストに申し込みを行い評価を開始し始めました。
　
まだその他の作業の関係もあり全然進んでいませんが、今後評価を実行した際には可能な範囲でレポートできればと考えています。
　
ただ、少しだけ触った感触では、『nifty mobile backend』レベルの完成度であるか？と問われるとやはり海外製のサービスである為、ドキュメントのレベルを含めかなり粗いというのが本音で、おそらく『nifty mobile backend』のような質を求めるのであれば正式サービス後のサポート状況を見てから検討した方がよいかもしれないというのが私の現状の認識です。
　

というか、今はベータテスト期間なのでそこは本サービス開始時点のGMOのサポート体制に期待したいところです。

　
このサービスの魅力はやはりプライスにあると私は考えています。
無料プランであっても従量制で柔軟に各種コール数や利用数を引き上げる事が可能ですし、中間プランとして月額9,800円のプランもあります。 最上位のプランは『nifty mobile backend』と比較すると３倍程のコストとなり割高に見えますが、コール数無制限/配信数無制限という条件ですので、サービス・アプリによってはコストの固定化が図れ非常に強い武器となるのではないかと考えています。
　
小規模〜中堅事業者にとってはやはりランニングコストというのは一番悩みどころ（サーバサイドのリソースも利用する形態のスマホアプリはヒットすると一気に負担が増加し、支援がないと継続する事も厳しくなるという事情もありますので）ですから、この手の柔軟な料金体系というのはやはりありがたいと感じます。
　
まだ具体的な評価に入れていませんが、時間を作ってある程度の機能をテストし他社サービスと比較できればと考えています。