Railsと AWSで業務システムを構築してみた

2013/11/02

広島 Ruby勉強会 #035

目次• 目的

• 対象

• 自己紹介

• プロジェクト構成

• システム構成

• 設計面の問題

• 実装面の問題

• 今後の予定

• 質疑応答

目的•Railsと AWSで業務システムを構築した際にはまったところを設計・実装の観点から解説します。

対象•業務アプリケーションに興味がある• AWS(Amazon Web Service)に興味がある

•アジャイル開発に興味がある

自己紹介•名前　カキギ　カツユキ•仕事　インターネット通販事業　　（ ECコンサルティング企画室）　

•趣味　山登り・ランニング

プロジェクト構成•期間•コスト•スコープ•組織体制•開発手法

プロジェクト構成•期間•６ヶ月•現在ステージング環境で運営•１１月から本番環境でサービスイン

プロジェクト構成•コスト•１００万円•クラウドの年間保守費用込み•担当者の人件費は計上していない

プロジェクト構成• スコープ

• 業務

• 販売業務

• システム

• 問い合わせ

• 受注

• 出荷指示

• 出荷

• 売上

スコープ（業務）

販売業務

在庫業務調達業務

会計業務

受注台帳

在庫台帳

注文台帳

売上台帳商品台帳

スコープ（システム）問い合わせ

問い合わせデータ

問い合わせ管理表

受注

受注データ

注文承諾メール

出荷指示

出荷指示データ

出荷指示書

出荷

出荷データ

売上

売上データ

売上伝票

請求締

債権データ

請求書

入金

入金データ

入金伝票

ピッキングリスト

納品書

送り状

出荷案内メール

発注

発注データ

注文書

入荷

入荷データ

入荷伝票

在庫データ

仕入

仕入データ

仕入伝票

支払締

債務データ

支払書

支払

支払データ

支払伝票

販売業務

調達業務在庫業務

会計業務

プロジェクト構成•組織体制•ネット通販事業部門・・・設計・開発•協力会社・・・開発・保守

コアチーム

協力会社

ネット通販事業部門

プロジェクト構成• 開発手法

• アジャイル開発

• プロジェクトマネジメント (SCRUM)

• Redmine

• 継続的インテグレーション

• Git

• Jenkins

• テスト駆動開発 (BDD)

• Rspec

• Cucumber

システム構成•移行前•移行後

システム構成•移行前•オンプレミス•パッケージソフト•自社システム

受注管理パッケージソフト

自社システム(MS Access)

システム構成•移行後•オンプレミス•パッケージソフト

•クラウド•自社システム

受注管理パッケージソフ

ト

自社システム(Ruby on

Rails)

DBサーバ(MySQL)

設計での問題•業務ロジック実装方式による問題•データ処理方式による問題

設計での問題•業務ロジック実装方式による問題

処理が遅い

処理が遅い

オンプレ

クラウド

設計での問題•業務ロジック実装方式による問題

処理が遅い

処理が遅い

処理タイミングを分離

設計での問題•データ処理方式による問題

受注管理パッケージソフト

自社システム(MS Access)

受注管理パッケージソフトからインターフェースしたデータはアップロード時にDBを全部削除してから登

録する

設計での問題•データ処理方式による問題

受注管理パッケージソフ

ト

自社システム(Ruby on

Rails)

DBサーバ(MySQL)

受注管理パッケージソフトからインターフェースしたデータはアップロード時に上書き更新登録する

設計での問題•データ処理方式による問題

受注管理パッケージソフ

ト

自社システム(Ruby on

Rails)

DBサーバ(MySQL)

インタフェース元データを削除した場合、そのデータを既に登録しているならば手作業で削除しなければな

らない。

設計での問題•データ処理方式による問題

受注管理パッケージソフ

ト

自社システム(Ruby on

Rails)

DBサーバ(MySQL)

データ内訳件数を明示して不整合を見つけやすくする

ことで対応

実装での問題•RDMSのパフォーマンスの問題

•リテラル値の使い方

実装での問題•RDMSのパフォーマンスの問題

• ステータスごとにデータを管理するのでOrder.where(status: [‘新規’ ,’出荷’ ,’確定’ ])というクエリを多用しているがMySQL5.5ではIN句を使ったクエリは遅い。

• 過去３年分の注文・売上データを保持するようになったので Order.allなどを実行するとえらいことになる。

実装での問題•RDMSのパフォーマンスの問題

• IN句の問題はMySQL5.6から改善されているのでRDSのバージョンをMySQL5.6にアップグレード

• インデックスを作成してチューニング (add_index :order, :order_number)

• データを確定と未確定に分けて通常の処理対象は未確定データのみとするようにする。Order.summaryなど検索対象を未確定データのみとするメッソドに変更

実装での問題•リテラル値の使い方def check_hoge

@order = Order.allif @order.ec_site = ‘楽天’

if @order.payment = ‘クレジット’case @order.sales_divisionwhen ‘1’

hoge1when ‘2’

hoge2end

endend

end

今後変化するかもしれない文字列を直接つかっている

区分情報が１とか２で業務的にわからな

い

実装での問題•リテラル値の使い方def set_name

@ec_site_name = {rakuten: ‘楽天’ ,

yahoos: ‘ヤフーショッピング’ ,amazon: ‘amazon’

} end

def check_hoge@order = Order.allif @order.ec_site = @ec_site_name[:rakuten]・・・

case @order.sale_divisionwhene Division.find_by_type(‘SALES’,’1’)

hoge1

名称はハッシュとしてモデルで一元的に管理できるようにす

る

区分情報を管理するマスタから取得するようにする

今後の予定• インフラの自動化

• vagerant(http://www.vagrantup.com/)

• chef(http://www.opscode.com/chef/)

• セキュリティの強化

• Amazon VPC(http://aws.amazon.com/jp/vpc/)

• 基盤技術の理解

• Ruby

• Rails

• 会計業務対応

• 財務会計

• 管理会計

質疑応答