2016年12月アーカイブ

こんにちは。

入社してから、詳細設計書の作成から開発、テスト実施、納品と数多くの経験をして参りました。

ブログラミング未経験の私が、入社から半年経ち大変だと思ったこと、為になったこと
入社前に何を勉強したら良いかわからない人に向けて私が感じたことを書きたいと思います。

【知識不足】
プログラミングを全くやってこなかったため、開発に携わってもその言語の勉強をすることから始めたので、人一倍時間がかかり、満足のいく結果が出せませんでした。
プログラミングをがっつりやりたい方は、時間がある学生のうちに自分が興味のある言語や、アプリの作成をしてみてはどうでしょうか。
私は、HTMLに興味がありましたので、1ヶ月程で取り組めそうな参考書を購入して勉強しました。

【詳細設計の重要さ】
詳細設計というのは、開発に入る前に、基本設計を元に、実際にどのように処理を行ってプログラムを動作させるかを決めていく仕様書になります。
なぜ、この詳細設計が大事なのか。自分がわかるように書くのは駄目だということ。自分が開発をするから、自分が分かれば大丈夫は禁物です。自分が書いた設計書を見ても案件に関わる方全員が理解出来るような設計書を作成しなければなりません。また、設計書を書く時点で疑問点をなくし、スムーズに開発に入ることも詳細設計の重要さの一つです。

【スケジューリングの大切さ】
スケージューリングとは、いくつかのやらなければならない仕事がある時に、どういう順番で進めていけば効率よくできるのかを決めていくことです。
案件には、納期という決められた日付までに全ての作業を終えて、お客様に納品をするという決まりがあります。
まずは、案件で各作業のスケジュールを立てていきます。そのチームで立てたスケジュールに対して個々でスケジュールを立てていきます。
立てたスケジュールに対して、自分の進捗はどうなのか、チームの進捗はどうなのかを毎日MTGの中で共有をします。スケジュールは社内全体で管理しているので、万が一スケジュールが遅れているとその時点でスケジュールを調節しなければなりません。万が一のことがあってからでは遅いので、早め早めにスケージューリングして全体を見通せるようにしなけらばならないのです。

他にも為になったことはいくつもありますが、長くなってしまいますので、今回はこの辺で失礼します。

はじめまして、アクセルユニバース システム部の今村と申します。

弊社では業務システムからスマートフォンアプリまで、所謂「なんでも」開発します。
Webアプリケーションも作成します。
直近では、 Ruby On Rails (以下、Railsと記載します) を用いた開発を多く実施してきました。

今回は、弊社で経験した マルチテナント環境でのRailsアプリケーション におけるちょっとしたTipsを紹介いたします。

1. マルチテナントとは

http://e-words.jp/w/%E3%83%9E%E3%83%AB%E3%83%81%E3%83%86%E3%83%8A%E3%83%B3%E3%83%88.html

上記のページに説明されている通りです。
同じWebアプリケーションを複数のアカウントで共有します。

弊社の開発において、Railsを用いたマルチテナント環境の場合は、１つのデータベース（PostgreSQLを利用）内にアカウント単位のスキーマを用意しています。
スキーマを分けることで、各アカウント単位のデータが混在する状態を防いでいます。

どのスキーマのアカウントからのアクセスなのかを判別するのには、サブドメインを用いています。

あるサービスのURLが「https://foobar.com/」であり、アカウントが「imamura」である場合、「imamura」用のURLは「https://imamura.foobar.com/」となるように設計しています。

ちなみに、これらの仕掛けはゼロから構築したのではなく、Apartmentというgemを使用しています。

http://qiita.com/kakipo/items/a584d24771dff019d3a9

2. rake db:migrate

Railsを用いたアプリ開発ではよく使うコマンドだと思います。
Railsにおけるマイグレーションの実行コマンドですね。

2-1. マイグレーションとは

念のため、マイグレーションについて簡単に説明しておきます。

Railsでは、データベースの操作（テーブルの追加、カラムの更新・変更・削除等）を、 マイグレーション と呼ばれる機能を使って行います。

通常、データベースの操作はSQLを実行すると思います。
これをマイグレーションで実施する場合は、マイグレーションスクリプトと呼ばれるスクリプトファイルを作成して、コマンドを実行するだけで済みます。

このコマンドが、上述の rake db:migrate になります。

参考：
http://railsdoc.com/references/rake%20db:migrate

2-2. マイグレーションの実行について

本記事では、 マルチテナント環境における マイグレーションと題しています。

この環境でマイグレーションを行った時、困ったことがありました。それは

rake db:migrate コマンドは、publicスキーマにしか実行されないということです。

前述の通り、マルチテナント環境は、同じテーブル構成を持つ複数スキーマを、それぞれのサブドメイン環境で使い分けて実現しています。

つまり、何かしらのデータベース定義の変更が必要となった場合、 追加したマイグレーションスクリプトの内容を、全てのスキーマに 適用させる必要が有ります。

3. マルチテナント環境でのdb:migrate

弊社で初めてRailsでのマルチテナントアプリを構築した場合、上述の問題については、意外と情報が見つけられず、困りました。
ですが、（本当にちょっとしたコトですが、）以下のオプションをコマンドに付け加えることで、publicスキーマ以外のスキーマにも、マイグレーションスクリプトの内容を反映できました。

$ DB=foo rake db:migrate

これだけです。DB=スキーマ名。

もちろん、db:migrate実行時の他のオプション（RAILS_ENV や up down など）も実行できます。

あまり大した内容ではありませんでしたが、マルチテナント環境に限らず、public以外の別スキーマにマイグレーションしたい！という方の参考になればと思います。

今後

DB=スキーマ名 オプションで、各スキーマへのマイグレーション実行できるのは良いのですが、アプリの更新時に、全スキーマの数だけコマンド実行するのが大変面倒です。

一括で実行できるスクリプトでも作って対応しようと思います。

はじめまして、AUCシステム部の田村です。

業務でサーバー構築を行う際は、AWS等クラウドサービスを利用するのがすっかり当たり前になりました。

新規構築したシステムを配置するため、インスタンスを契約しようとするとき、AWS 料金表を見ていてもどれを選べばよいのかよく悩みます。

AWS 料金表（EC2オンデマンド）

https://aws.amazon.com/jp/ec2/pricing/on-demand/

私がサーバー選びをする際に実施しているポイントや苦労した点について複数回にわたってまとめたいと思います。

サイジングとは？

インターネットで調べてみると、下記のように説明されていました。

サイジングとは、システムやその構成要素について、必要とされる規模や性能を見極めて用意したり、状況に応じて適切な規模に削減あるいは増強を行うこと。
『IT用語辞典 e-Words　http://e-words.jp/w/%E3%82%B5%E3%82%A4%E3%82%B8%E3%83%B3%E3%82%B0.html 』

サイジングの方法

サイジングは、大きく3つの作業に分かれます。

1.利用規模の想定

2. 利用規模を満たすスペックのサーバー選定

3.運用後の値と想定値を比較し、スペックの見直しを行う

利用規模の想定

私は、利用規模を想定するとき下記の観点で、洗い出しを行っています。

コンテンツのデータ量の決定

システムに対して1回アクセスした際に発生するデータの量を決定します。

・1ユーザーがアクセスした際に利用するデータ容量
例えば、WebページならHTMLのファイルサイズ、画像コンテンツの容量などです。

・1ユーザーが登録するデータ（テキスト、画像）の容量

利用数の想定

対象とする母数に対して、何%のユーザーがこのシステムを利用するか、想定します。想定が難しい場合は、何ユーザーまで利用できるようにするか、見込の値を決定します。

・ 1ユーザーが1ヶ月間に平均で登録する回数

・1ユーザーが1ヶ月間に平均で閲覧する回数

システムに必要なデータ量、性能の決定

『コンテンツのデータ量の決定』と『利用数の想定』ができれば、そこから『システムに必要なデータ量、性能』が決定できます。

私はこれをExcelに項目ごとにまとめ、一ヶ月間に必要なスペックを算出しています。

利用規模を満たすスペックのサーバー選定

システムに必要なデータ量、性能が決定したら、いよいよサーバー選定です。

AWS等クラウドサービスの料金表には、どのグレードのサーバーだとどれくらいの性能があるのか項目ごとに詳細に記載されています。これを参考にして、『システムに必要なデータ量、性能』を満たすサーバーを決定していきます。

https://aws.amazon.com/jp/ec2/instance-types/

性能が決定したら、今度は料金の計算です。AWSの場合、Web上で見積を行うツールが無料で公開されています。必要なサーバーをマウスで追加していき、必要な性能を入力すれば、自動的に料金を計算してくれます。

http://calculator.s3.amazonaws.com/index.html?lng=ja_JP

また、見積算出ツール内の『保存して共有』をクリックすれば、専用のURLが発行されるため、簡単に共有することができます。

運用後の値と想定値を比較し、スペックの見直しを行う

実際にサーバーを運用すると、常に想定通りの構成になるとは限りません。実際のデータ量、利用数を測定し、再度『システムに必要なデータ量、性能』を見直します。

AWS等のクラウドサービスは、運用開始後にサーバーの性能を簡単に変更できるところが魅力です。

次回は、1つシステムを想定してサイジングを行って行きたいと思います。