トップ 最新 追記

2015-12-01 [長年日記]

_ Composerで必要なrepositoriesは全部書け、の話

分かったこと

composer で install する package が pear など外部の repository に依存している場合、その依存 repository は composer install の実行対象の composer.json に書かれていなければいけない。

+----------------+    +-------------------+    +---------------+
|(1)composer.json| -> |(2)composer package| -> |(3)pear package|
+----------------+    +-------------------+    +---------------+

上の図のようになっている場合、(2) の composer.json だけでなく、(1) の composer.json にも repository の追加が必要。

composer 1.0-dev (d79427f1a7b15e8f4d46ce8124a4d0c58ba1479c) で試した。

composerでpear packageを扱う場合

  1. 自作ライブラリ(非公開)をcomposer対応した
  2. このライブラリは pear に依存しているので以下のような記述を追加した
"repositories": [
   {
     "type": "pear",
     "url":  "http://pear.php.net"
   }
]

ここまでは前回も実験してるし、探せば出てくる情報。

cf. 今さらComposer - あーありがち(2014-07-02)

composerはrepositoriesを再帰的に解決しない

みたい。

上の図で言うと (2) で repositories を追加しているので (1) には書かなくていいんじゃないかと思ったんだけど、そんなことはなくて、(1) に repositories を追加しないと、

requires pear-pear.php.net/http * -> no matching package found.

みたいなエラーが出る。

頑張って package の指定のミスを探したけど、何のことはない、単に repository を追加していなかったからであった。

まとめ

  • pear など repositories の追加が必要な composer package を利用する場合は install の実行対象となっている composer.json にも repositories の追記が必要
  • 自分でそのような package を作る場合は README など install 方法にもその旨但し書きせよ

というお話でした。以上。


2015-12-18 [長年日記]

_ CircleCIに最新のSQLite3をインストールした状態でsqlite3 gemを使う

ちょっと複数の問題が混ざっていて難儀したけど、切り分けたうえでタイトルの話が解決したのでナレッジをシャアさせていただきます。

まとめ

かっこつけて Tl; dr とか書く必要なくね? まとめでよくね?

  • ruby の native extension は gem のバージョンの他に build 前のソースのバージョンにも気をつける
  • ssh や伝統的なコンパイルの方法*1とか知ってると便利!
  • CI の整備をするのってやっぱアプリの開発とは違うノウハウが要るんだなぁ〜

じゃあ何が起きて何が分かったか順にいきましょう。れっつらごー。

activerecord-importを使ったらCircleCIでSyntax Error

activerecord で bulk insert をやりたくて activerecord-import を使ったんですよ。

ActiveRecord のバージョンによって対応してるバージョンが違うので、それに気をつけてインストールしましょうって程度で、開発自体は特に難しくない。サクサクと進んでテストも済んで、よしよしと思っていたんだけど、よしじゃあ pull-req ってみますかねと思ったところで、

ここで生成されるSQL

INSERT INTO "tables" ("id", column_name1, column_name2, ...)
            VALUES (NULL, value1, value2, ...)

が SyntaxError になってしまうという問題に遭遇。

しかも CircleCI でだけ。うへえ。

SQLite 3.7.11のinsert文拡張

SQLite Release 3.7.11 On 2012-03-20

ここに書かれている

  • Enhance the INSERT syntax to allow multiple rows to be inserted via the VALUES clause.

がポイント。つまり CircleCI の SQLite3 が 3.7.11 より古い可能性がある。*2

2015-12時点でCircleCIはUbuntu 12.04

CircleCI の環境はサイト上に記載されている。

Base

Our base image uses Ubuntu 12.04, with the addition of many packages commonly used in web development. Some specifics:

  • Architecture: x86_64
  • Username: ubuntu
  • Ubuntu 12.04 (precise)
  • Kernel version: 3.2
  • git 1.8.5.6
  • gcc 4.6
  • g++ 4.6
  • GNU make 3.81

via. https://circleci.com/docs/environment

各種言語のバージョン情報などはたんまりあるが、残念ながら SQLite3 に関する情報はない。はてどうするか。

CircleCIのbuild環境にsshでログインする

ここから急にサーバ管理方面の知識が必要になる。イマドキ(小規模な) Web アプリの開発や deploy に ssh は不要だと思ってたけど、CI のおまかせセットから外れるには力が必要なのだ。

CircleCI には build 環境に ssh で繋ぐ方法があり、それはちゃんとドキュメントに書かれている。

SSH access to builds - CircleCI

2015-12-18時点でまだサービスのデザイン変更にドキュメントが追従していないが、まぁやり方は一緒である。

ここで接続には GitHub に登録してある鍵を利用する のがポイント。

ssh 接続の際に何が起きてるかよく分からないという場合は -v オプションを重ね打ちするとよいぞ。今は Windows の人も openssh が使えるらしいので、ナレッジが共有できて便利ですね。

で、

sqlite3 --version

と叩くと 3.7.9 と返ってくる。間違いない、こいつだ。

そもそも native extension とは

SQLite3 に限らないんだけど、native extension とはざっくり言うと

Ruby と、 C などの Ruby の外の世界を繋いでいるもの

である。

この繋ぎ方に作法があり、SQLite3 で言うと

  1. SQLite3 の C言語のヘッダやコンパイル済みのライブラリを準備しておき
  2. `gem install` の際に Ruby とリンクする

という作業を行う。よく CentOS など yum の世界では

yum install sqlite-devel

Debian / Ubuntu 系の世界では

apt-get install libsqlite3-dev

しておけと StackOverflow などで Answer が出ているが、これは上の 1 の準備をしているという意味である。

つまり sqlite3 gem で言うと

  • sqlite3 gem のバージョンの他に SQLite3 本体のバージョンがある
  • CircleCI では SQLite3 本体のバージョンが古い
  • CircleCI の SQLite3 のバージョンを上げなきゃならない

Ubuntu 12.04のSQLite3を新しくするには

大きく二つ方法がある。

Debian 系の distro では apt でインストール可能なパッケージの配布元の設定をいじることで distro 標準のバージョンよりも新しいパッケージを入れることができる。これが一つ。

もう一つは cache と野良ビルドを使う 方法だ。

CircleCI でも apt-key から sources.list を更新してパッケージ全体を更新するというのはできなくもなさそうなのだが、そこ突っ込んで失敗すると時間の損失がでかそうだし、そもそも今やりたいのは CircleCI で使っている Ubuntu 全体の管理を刷新するということではなく、単に SQLite3 のバージョン上げろってことなので、ドキュメントや情報の揃っている、後者の方法を採用することにした。

誰か apt から新しいバージョンのインストールした方が簡単だよという手順を確立したら教えてください。

※ 古い話だと distro は Debian stable を入れておきながら一部のパッケージだけ testing から持ってくる、みたいなテクニックがあるのだが、そもそも Ubuntu って Debian testing ベースだし、いやいや、Ubuntu LTS ってもう次の 14.04 が出てからずいぶん経ってるよね、みたいなことを思いながら、粛々と古式ゆかしい作業に突入していくのであった。

CircleCIでSQLite3を野良ビルドする

ものによって気をつけるべきポイントは違うと思うが、SQLite3 の場合は面倒な依存もないのでとっても簡単。

https://www.sqlite.org/2015/sqlite-autoconf-3090200.tar.gz

からソースを取って来てビルドするだけ。こんな感じだ。

wget https://www.sqlite.org/2015/sqlite-autoconf-3090200.tar.gz
tar zxf sqlite-autoconf-3090200.tar.gz

cd sqlite-autoconf-3090200
./configure
make

コーヒーを抽出する前に終わる。

configure とか make とかイマドキだとやったことのない人も多いかもしれない。Web アプリ作るだけなら実際必要ない知識になりつつあるけど、こうして必要になるシーンもあったりするので、若い人も時間を見つけて「とりあえずコンパイルしてみた」みたいな経験をするのもよいことなのかもしれない。*3

逆に年寄りでサーバ分かるよと言いたい人はこういう形で経験を生かせるとより全体の幸福に貢献できるので、積極的にイマドキの環境を試すのがよいと思う。

make installとgem install

さて、上の手順では普通やるはずの作業を一つやってない。

make install

だ。これは文字通り今コンパイルしたツールを利用可能な状態にインストールする作業で、普通は root 権限が必要なので

sudo make install

と実行する。

結論から言うと結局この通りに実行するのだが、考えなければいけないのは

今やろうとしていることはbundle install

だということ。

というのも、実は bundle install に当たって以下のことを考える必要がある。

  1. CircleCI ではすでに SQLite 3.7.9 のライブラリがインストールされている
  2. gem install の際に標準ではない依存ライブラリの場所を指定する必要がある
  3. gem install のオプション指定を bundler に教えてやる必要がある
  4. その指定したい場所にヘッダとライブラリを置く必要がある
  5. gem install の際には gem install で標準的に想定しているライブラリやヘッダの配置があり、それに従っていないとすごく面倒

ふー。やっぱ野良は面倒だ。

/usr/localに入れる

前述の 1 と 4, 5 の課題を一気に解決するのは

sudo make install

すること。

Debian 系では apt でインストールするパッケージは /usr 以下に、野良で入れるものは /usr/local 以下に、というルールがあり、何も考えずに make install すると /usr/local 以下にさっきコンパイルした SQLite がインストールされる。*4以下のような感じだ。

/usr/local/include/sqlite3.h
/usr/local/lib/x86_64-linux-gnu/libsqlite3.a
/usr/local/lib/x86_64-linux-gnu/libsqlite3.la
/usr/local/lib/x86_64-linux-gnu/libsqlite3.so

ということで /usr 以下に SQLite 3.7.9 が、 /usr/local 以下に 3.9.2 がインストールされる。問題なく同居できる。

で、くり返すが大事なのは gem install 時にもこのような

{prefix}/include/
{prefix}/lib/

といった配置が期待されているということ。だからあとは bundle install 時に /usr 以下ではなく /usr/local 以下の SQLite3 をリンクしてくれるように教えてあげることができればオッケーだ。

gemに/usr/local以下のSQLite3を教える

ここが分かりにくい。native extension の作り方を知ってしまえばいいのだろうが、普通は native extention は作りたいんじゃなくて使いたいのだ。

とりあえず sqlite3 gem では `tasks/vendor_sqlite3.rake` の中にある `--with-opt-dir`が使える。具体的には

gem install sqlite3 -- --with-opt-dir=/usr/local

とすると目的を達成できる。

試しに上を実行して本当に新しいバージョンの SQLite3 を使っているかどうかは

ruby -e 'require "sqlite3"; p SQLite3::libversion'

で確認できる。

bundlerに/usr/local以下のSQLite3を教える

実際には CircleCI で動かすには普通は bundle install を利用して gem を入れているはず。gem コマンドに与えるオプションを bundle から指定するには

bundle config

コマンドを使う。

bundle config build.sqlite3 --with-opt-dir=/usr/local

とすると sqlite3 を build する際のオプションを指定できる。

CircleCIで野良ビルドしたアプリを効率的に利用する

さて、ここまでの処理を circle.yml から呼び出せるようにすると、

  • CircleCI で build する際に自動的に最新の SQLite3 をインストールして
  • それを利用して bundle install して
  • テストを実行する

ことができるようになるわけだが、普通に考えて すごく重たい ことは想像に難くない。

そこで cache を利用する。

cacheの指定とpre build処理

CircleCI の build 時に事前の処理と、その際生まれた成果物を再利用できるように cache するディレクトリを指定することができる。

具体的にはこんな感じ。

circle.yml

dependencies:
  cache_directories:
    - "~/sqlite3"
  pre:
    - ./_circle_script_install_sqlite3

注意しなければいけなのは ~ による $HOME の展開を YAML 上で期待する場合は quote する必要がある点。ちゃんと本家のドキュメントでは quote されているのだが、日本語のブログエントリを探してると、ここを検証せずに quote なしの記述を載せている場合がある。

本家のドキュメントを当たるのが何よりも基本

なので、ちゃんとドキュメント探そう。ついでに sqlite3 のインストールと bundle config 用のスクリプトも載せておく。

_circle_script_install_sqlite3

#! /bin/sh

if [ ! -e ~/sqlite3 ]; then
    mkdir -p ~/sqlite3
    cd ~/sqlite3

    wget https://www.sqlite.org/2015/sqlite-autoconf-3090200.tar.gz
    tar zxf sqlite-autoconf-3090200.tar.gz

    cd sqlite-autoconf-3090200
    ./configure
    make
fi

cd ~/sqlite3/sqlite-autoconf-3090200
sudo make install

bundle config build.sqlite3 --with-opt-dir=/usr/local

cache を使うので sqlite3 内の make の成果は消えない。つまり、コンパイルに掛かる時間はゼロになる。ただし、ライブラリのインストールは毎回行っている。

わざわざ毎回 make install と bundle config を叩いているのは、どうにも build が安定しなかったためで、本当は要らないかもしれない。

これで快適CircleCI + 最新SQLite3生活のできあがり

というわけで無事 CircleCI で SQLite 3.9.2 を使って activerecord-import を使ったコードのテストが通るようになりました。長かった。

ということでもう一度まとめ。

gem について

  • native extension は gem のバージョンだけでなく、利用しているソースのバージョンも大事

CircleCI について

  • build 環境に ssh でログインできる
  • 独自アプリのインストールができる
  • cache をうまく使えば独自アプリインストールをスキップして build 時間を削減できる

その他

  • C で書かれたプログラムの手動コンパイルの方法、Un*x系 のディレクトリの配置ルールなど古い知識も役に立つ
  • build 環境もコードで制御するとさらに幸せな CI 生活を送れる

おっさんの経験が不要になる環境は揃ってきているが、おっさんはおっさんで貢献できる。ちゃんと「枯れる」ノウハウ、スキルを身につけていきたいもんだなと改めて思ったのでした。

*1 ./configure; make; make install

*2 ここにそんなすぐたどり着けるかというと、そこは微妙。いろいろ試行錯誤は必要だと思う。

*3 Make を知っておくとイマドキのタスクランナーの話題を理解しやすいかも

*4 この辺は distro というか OS ごとにルールが決まっている。


2015-12-31 [長年日記]

_ 2015年のお仕事ふりかえり

久しぶりに年末にふりかえりのエントリが書けるかな。頑張ってみよう。

クラウドとよくできた通知システムとしてのチャットを取り入れた

昨年度から production 環境のクラウド化、リポジトリを社外ホスティングに移行、チャットシステムを入れ始めた。具体的には AWS S3, GitHub, Bitbucket, Slack, Sqale, EngineYard, Heroku, Papertrail, SendGrid, Redis Cloud, NewRelic, CircleCI, Codeship, DNSMadeEasy 辺り。S3 だけは以前から使ってたかな。今年はいろいろ噛み合って動き始めた感じ。

いちばんの動機は自分の仕事の中での「サーバ管理系の雑務」の割合を減らすことと外注と組めるようにすること。*1

もう一つの欲としては「この地域でもこういう面白い道具使って仕事してるとこあるんだぜ」というアピールなんだけど、これはまだうまくいってないので、それ以外の成果を書こうと思う。

いちばんうまくいってるのはゼロから自分の手で立ち上げた Rails プロジェクトで、これについては先日の CircleCI のエントリもそうだけど、GitHub, CircleCI, Heroku, Slack, NewRelic がバッチリ連携できてて非常に快適。気に入ってるのは以下の設定。

連携 用途
GitHub -> Slack プロジェクト用のchannelで通知なし
GitHub -> CircleCI -> Heroku production, staging へ自動deploy
CircleCI -> Slack testの成否とdeployスクリプトからのPOSTを通知用のchannelに
NewRelic -> Slack error通知用のchannelに

メール通知を完全にゼロにはできていないけど、日常的に「自分以外の人の動き」「アプリの負荷が上がった」「アプリのエラーが増えた」などが比較的小さな負荷で見えるようになった。

以前のサーバでは log からお手製の swatch みたいなやつを仕込んだりしてたけど、メールより断然スマホアプリと連携できて通知の on/off を細かく制御できる Slack が楽。できることが増えたので管理系の雑務自体が減ったかどうかで言うと実は微妙だけど、以前より全体の状況はつかみやすくなっていて、この部分が2015年最もライフチェンジングだったように思う。

この辺りは Kanazawa.rb の meetup では話題に出してはいるんだけど、日常的にこういうの使ってる会社はこの辺じゃあまりないので、工夫を共有するみたいなところまでは行ってないのが残念。ぶっちゃけると言語の話よりこういう話の方が好物ではあるので、みんながガンガン使えるようにおれが事例を作ってやるぜ。

そういや JAWS x Hokuriku.NET x Kanazawa.rb 合同勉強会でこの辺りの発表した資料上げてないけど、どういう理由で上げてないんだっけ。あぁ、たぶん単純にものすごく大変な時期だったんだろう…。

Kanazawa.rb x Hokuriku.NET x JAWS-UG北陸 : ATND

クラウドを前提にしたWebアプリの楽さと難しさ

とにかく環境の構築、スタートが楽、だけど作法は守ろう

というわけで、世界あるいはトーキョー的には今さらな感はあるけど、自分の中ではクラウド化というのが2015年のいちばんホットな話題。

実際には PaaS でやりますという決定だけして自分でやってないやつ、途中まで自分でやったやつ、立ち上げは自分でやって、移行を他の人にお願いしたあとにチューニングがまた自分の手元に戻ってきたやつなど、いくつかある。

いちばんライトなやつはポチってアプリ作ってポチってリポジトリ作って、bundle install と push しておしまい、みたいなやつで、これは本当に楽になったなーと感じた。サーバに何が入ってて、とか何も気にしなくていい。.ruby-version と Gemfile.lock で決まる。Capistrano の設定も要らない。さすがにカップラーメン作るよりは時間掛かるけど、こんなんでいいんすか、という楽さ。

もちろん、そんな楽なものばかりではなくて、どれも一長一短というかうまくいっているところとそうでないところがあるんだけど、Heroku + Rails で動いているものが今のところいちばん「環境」としては楽。

とにかく環境が portable なのがとてもよい。development と production では middleware は割と違うんだけど、ちゃんと抽象化されているので production でしか動きませんということがほぼない。(なくもない)

12factor 的には当たり前の話なんだけど、これが実は当たり前じゃあないんだ。

というのも、いわゆる「本番での動作しか想定していない」という作り方をしてしまう人はやっぱりいる。結局その辺は PaaS か否かは関係ない。具体的には

  • 秘密情報がハードコーディングされてる
  • 画像アップロード周りで S3 の URL をそのまま DB に書いちゃう
  • Nginx の設定に依存したコード書いちゃう
  • reverse proxy の動作に依存したコード書いちゃう
  • メール周りが SendGrid にベッタリ依存してて development や test で困る

それでいて

  • ストレージが揮発することを忘れたコードを書いちゃう

2015 年だよー。Rails 登場から10年だよー。こんなことやったらテストの自動化も deploy の自動化も難しくなるじゃん、と自分は思うんだけど、そもそもそんな考えがないんだ。社会は厳しい。

こうなっちゃうと何が起きるかというと、単に PaaS はいろいろバラついてて制限が強くて面倒な環境だってことになっちゃうんだね。違うよ、そこは世界の優秀な人が書いたフレームワークがお守りをする部分で、自分で工夫して書いちゃダメなんだよ。自分で工夫して書いた部分がボトルネックになるのであって PaaS が悪いんじゃないよ。

確かにね、「ある程度から先の領域」に入ったら自分で工夫しなきゃいけないところは出てくる。でもほとんどのコードは過去の自分のやり方ではなく、世界の先達の作法に従った方がマシなんだ。だからちゃんと世界を知りなさいという話に尽きる。自分の過去、自分が今思いついたこと、隣の同僚、そういうレベルだけで仕事していいのはごく一部の人なんですよ。

話がそれた。要はちゃんと楽するための作法を知れということです。

楽するための作法を守っていないとどんどん開発速度は落ちていく

のだから。

例えば本番でしか動かないコードをコミットしたら「ローカルではちょっと書き換えて動かす」みたいなアホな手間が生まれる。一度入れたらその後ずっと開発コストは上がった状態になるし、まずミスる。「S3 が動いていれば ok」というコードにすると開発用の S3 が欲しくなる。逆に面倒になって画像が絡む部分はローカルではテストしなくなる。

開発コストを上げて品質を下げている原因は環境じゃない、開発者の姿勢とスキル。

これも2015年によく感じたことの一つだった。

まぁ、開発者のやる気を削いでしまう環境はあるかもしれない。残念ながら。でもそれを言い訳にして改善をしないのなら、そこを辞めた方が結果的にプロダクトを受け取るユーザーはハッピーになるんじゃない? 君のコードは何のためにあるんだ。アホな組織のためにあるのか?

また説教くさくなった。いかんいかん。

構築は楽だけど IO のコストが見えるようになる

いろいろ楽になったけれど、PaaS は基本的に何もかもバラついているというのは事実で、環境の構築と再現は楽だけど、アプリは常に IO との戦いというのが見えるようにもなってくる。

Heroku + Rails のアプリの中の一つは徐々に

  • ストレージを S3 に追い出す
  • 開発環境を Vagrant Box に
  • Ruby, Rails のバージョンアップと Heroku 移行
    • 開発環境を生 OS に(必要に応じて Foreman / Dotenv)

と変化させていった。いびつになってしまっている部分もあるけど、Rails と便利 gem のおかげで特に環境の切り替えがとても有効に使えていて、移行も比較的スムーズに行えたと思う。実際にはこのリポジトリを GitHub に置いて Heroku 化するダンドリだけ自分でやって移行作業は別な人にお願いしたんだけど。(並行して自分は何やってたかというと、全然違うプロジェクトが動き始めてそっちの設計と打ち合わせに掛かりっきりになっていた。)

今年の日記がぽっかり空いてるのはその時期で、これが実際に動き始めたら AWS の us-east と ap-northeast って遠い*2なーというのが最初の課題。それまでもなんとなく S3 使い始めてから遅いなーと思ってたけど、サーバが海外に行っちゃってから遅さがいろいろなところで爆発&管理系の要件が妙に重くなってきて、正直 Heroku めっちゃ遅いのでは?と思ったけど、単に実装がまずいだけだったという結論が出るまで、あれこれ試行錯誤が続いた。

最終的には

  • S3 への無駄な通信が生まれないように手直し
  • 妙に asset(特に画像)が多く、しかも cache の効かない書き方だったのは CDN に丸投げ
    • 今はどんどん画像をなくすようにしている
  • えいやで全部書き換えてた DB のレコードを必要なものだけに絞る
  • クリティカルなものからバックグラウンド処理に移行(Sidekiq の dashboard かっこいい)

みたいなことをやってた。あとは jpmobile をちょっと独特な使い方してて、それが Ruby と Rails のバージョンアップ時に悪さして、GC 止めたり元に戻したりと、

とにかく NewRelic をよく見ていた時期だった。

サーバ管理をしなくて済むように PaaS にしたらアプリもインフラも見るようになってた。一周回って元に戻る。

とは言え、「探る方法がポチだけで用意できて、しかも分かりやすい」「解決策がある」というのがいちばんの救い。その分、仕組みを考えるに当たって以前より広い視野を求められるようになった。そこはよい機会と捉えている。

次点

  • PHP で packagist を使ってライブラリ公開
  • Google Apps Script を使って管理画面をゼロから作らない

これも以前より方法の幅が広がった話。詳細は割愛。

その他

  • PowerAssert を production で(?)使い始めた
  • Mixpanel を一部で入れたり Google Analytics の staging 環境を用意したり、この辺はまたの機会に。
  • Browserify と Mithril の実験。これを Rails 以外にも展開できると面白そう。
  • 本を読む時間が全然なかった。WebAPI, Mithril とあとは縦書きの本を少々。

でも実は技術じゃない課題がどんどん膨らんでいく…。考えられる人が足りない。(足りないのは己の能力か)

今後の課題

今後はとにかく布教活動かなぁ。今のやり方はハマればすごくいいと思うんだけど、知らない人と組むことはできない。とにかく手が足りないので外部と組む必要があるけど、求めているのは「ちょっと Linux サーバ立てられます」みたいな人じゃない。ところが PaaS の経験のある人が地方にはとても少ない。pull-req を merge しただけで deploy できる環境があるって実感できてる人が少ない。ついでに言うと REST とか resource とかトランスパイラとか React系のフロントエンドの動きとか、ね。

まぁ東京のまねごとをしてるので東京に頼めばいいんじゃないの?という話になるかもしれないけど、予算がね…。ううう…。

布教の話はあんまり言うと全部自分が教える系になりかねないので、それは避けないといけない。じゃあどうやって盛り上げていくのかを考える必要はありそう。

あとはハードウェアまで含めた新しいことをやっていきたいなーなんてことを思いながら最近になってようやく RasPi とか Arduino とか調べてた。たぶん自分がやりたいことにいちばん近いのは Intel Edison Kit for Arduino なんだけど、もうちょっと手軽なものからちょこちょこと遊んでアイディアを膨らませていきたい。

*1 もう一つはちゃんとサービスごとに経費が分かるようにすること。

*2 すでに S3 が ap-northeast で稼動してた