JAWS-UG三都物語_企業でのAWS導入のエントリーポイント

企業でのAWS導入のエントリーポイント

2013. 3. 9
アールスリーインスティテュート
金春利幸

〒541-0053 大阪府大阪市中央区本町2-3-4-8F
電話：06-6271-3663
Mail: info@r3it.com
Web: http://www.r3it.com/

自己紹介

【名前】金春利幸（こんぱるとしゆき）
珍しい名字ですが・・・ご存知の方は、
能楽の金春流をご存知かと・・・ Tips! 銀座に金春通りという
通りがあったりします

【お仕事】アールスリーインスティテュート Founder & Manager
• 普段はプロジェクト・マネジメントと上流工程を担当
• 社外および社内でのAWS導入の先鋒を担当

【好きなAWSサービス】Route53
• それまでDNSサーバの管理がめちゃ面倒だった
• Route53使ってすごく楽になった

Copyright 2013 R3 institute All rights reserved. 1

システム開発の上流から下流まですべて自社で一貫して、ご提供するシステム開
発会社です

弊社アールスリーインスティテュートについて

法人向けサービス
・業務系システム
アプリ・対消費者システム
ケーショ・工場系、機器制御系システ
ム
ントータルサービス
・研究サポートシステム
・各種コンサルティング

ミドル各種DB、APS、フレーム調査システム仕様・開発
導入運用・保守
ウェアワーク業務分析要件定義テスト
など

Windows iOS
ＯＳ Linux
COBOL
Android
など
ファンクショナル・サー
ビス
・業務分析、業務の「見える」・システム開発・システム保守
化・フレームワーク設計・ＩＴ全般サポート

インフ
AWSを利用・データ分析
・システム企画
・プロトタイプ開発
・ベンダーマネジメン
・技術的ＱＡ
・現行システムのド
各種サーバ
ラ・全社内システムの最適構成設トキュメント化
ホスティングハウジン計・クラウド化・ＰＧトレーニング
グ・現行システム評価・サーバ冗長構成設計
・パッケージソフト評価・ユーザテスト代行
・ＩＴコンサルティング・業務マニュアル作成
・他社製品導入
・現場教育
・メンテ運用設計


2006年のスタート当初からウォッチはしていましたが、本格的な導入は2011年
から・・・

弊社がAWSをプッシュし始めたきっかけ

AWS本格導入のきっかけは、3.11 でした・・・
関西からは尐し遠くのことと思っている方も多いようですが・・・
3.11 弊社社員が仕事で仙台にいました
（私も関与しているプロジェクトでしたがたまたま私は行ってなかった）

弊社社員を脱出させるために様々な手をつくした結果・・・


2006年のスタート当初からウォッチはしていましたが、本格的な導入は2011年
から・・・

弊社がAWSをプッシュし始めたきっかけ

① 山形から仙台へタクシーを向かわせる
② 仙台から山形空港へタクシーで
③ 山形空港から伊丹空港へ


明日は我が身ということで、まずBCP・DRとしてAWSの利用を開始したが、
使ってみると
とても便利ということで・・・

弊社とAWSの関わり

2011.3 社内サーバの大半をAWSに移すことを宣言

弊社のAWS１号案件がローンチ（ぎりぎり東京リージョン間に合わず）

2011.6 基本的にほぼすべての提案で稼働環境としてAWSを検討することを宣言
・・・・

提案活動を通じて徐々にAWSを導入していただくケースが増えてくる

2012.12 AWSパートナーに登録


システム開発会社はプロジェクトごとに開発サーバが必要となります。リリース
後にも保守のため維持しないといけないため、プロジェクトが増えるにつれて
サーバ台数も増えていきます

弊社自身のAWSの使い方

気がついたら、社内がサーバだらけに・・・・

VMwareで社内で仮想化してみた・・・

一旦減ったものの、当然しばらくたつとサーバが増えだした。
しかも、プロジェクト間でリソースの取り合いになり使い勝手が悪い

AWS化で、社内の開発サーバを一掃（過去のものは尐し残っている）

スッキリ！しかも、下がった電気代くらいでAWSの料金がまかなえる


一部サーバは社内に残っていますが、これらも順次AWSに移す方針です

弊社自身のAWSの使い方


企業にAWSを導入していくときの問題点などをお話します


クラウド型のサーバおよびサービスに対する理解がまだまだ低い・・・

クラウドに対する妄想

• クラウドだからサーバ壊れないんでしょ？
壊れる。壊れる前提で設計する。
ただし、壊れても大丈夫にする術が簡単

• クラウドだからデータ消えないんでしょ？

消える。ただ消えないようにするためのバッ
クアップ手段が安価に豊富に用意されている

• クラウドだから安いんでしょ？
概ね合ってるが場合による。ただ安くするた
めの手段がたくさんある


実際のところ、入り口の入り口と言えるところで尻込みされている方が多いです

AWS導入で尻込みされるポイント・・・

• AutoScalingとかすごいけど、うちにはそこまで必要なサーバがない

• データセンターに入館できないけど大丈夫なの？データセンターに行かな
くても運用できるってどういうことなの？

• クリックぽんぽんでサーバ起動できるってほんとなの？

• ドル払いはちょっと・・・これから円安に向かうでしょ・・・

• セキュリティが心配・・・

• 自分のところで仮想環境作った方がいいんじゃないの？

• 外資って大丈夫なの？パトリオット法大丈夫なの？

• 日本企業だと、なんかあったら駆けつけてくれるし、いいんじゃないの？


いきなりがっつり導入しなくていいんです。

できるところから入れていけばいいんです。

できるところから入れたらそれ相応に安いのが
AWSのいいところです

とっかかりに丁度いい事例はたくさんあります。

これから、いくつか事例紹介をします。難しい
事例はありません。技術的には面白くありませ
ん。ごめんなさい。
でも、企業にはこれが重要なんです


すべてのシステムが常に利用されるとは限りません。月に一定時間しか使われな
いシステムであれば、AWSなら使わない時間止めておくことでかなり安価に利
用できます

事例1: 月に一定の期間しか利用しないシステムの構築
AWSでの構築のメリット
• 月末・月初の締日前後にしか利用しない請求書処理シ
ステム（締日前後5日、日中8時間だけ利用できればよ
い）
• 多尐のダウンタイムは許容できるが動いているべきと
きは確実に動いていて欲しい
• とはいえ、サーバに対して面倒な運用作業はしたくな
い

AWSで必要な時だけ起動すればよい

• AWSならスクリプトを書いてAPIを呼ぶことでマシ
ンの起動も停止も自動的に思いのままできる
• 止めている間はほとんど課金されない
• 稼働期間中は、しっかり監視する仕組みにすること
で動くべきときに確実に動いているという仕組みを
構築できる

これなら13,000円/月程度で運用できる


実験的プロジェクトでは、IT部門を通さずに現場だけでやってしまうこともでき
ます

事例2：製造業でのAWS導入
AWSでの構築のメリット

• 実験的プロジェクトでもIT部門を通す
と全社インフラが・・・等で頓挫して
しまうことがある。AWSを使って全社
インフラとは無関係に構築すれば、ス
ムーズに実験できる
本社でリアルタ
イムに生産状況 • 製造業へのシステム導入はラインの邪
を把握・分析魔をしないようにスモールスタートで
生産上の様々な実験を繰り返していく必要があるため
データをタブいきなり大きなサーバは用意できない
がAWSならスモールスタートできる
レット端末で入
力し、 AWS 上 • 対応工場の増加に伴い、サーバをス
のサーバへ送信ケールアップ・アウトさせやすい

• 規模に応じて、適切なバックアップや
リカバリーの手段を用意していける

• 協力工場の参加も、AWS上に構築して
おけば自社ネットワークにほとんど影
響を与えないため、容易


社内での「クラウド化」の号令でプライベートクラウドに移行してみたが・・・
柔軟性がなく結局オンプレとの違いが見いだせない

事例3: 他社プライベートクラウドからの移行
プライベートクラウド AWS

• 契約し確保したリソースの範囲内で • リソースはほぼ無限にあると思って
サーバを構築しないといけないいい
（サーバ間でリソースの取り合いに
なる） • 使いたいときに使いたいだけサーバ
を使える。不要になればいつでも消
• 一時的にテストサーバを増やしたいすことができる
と思っても、リソースが足りないと
できない • サーバの追加は数分でできる。（自
動的にもできる）
• サーバを追加を依頼しても数営業日
かかったりする • ストレージのI/Oパフォーマンスを自
由に指定できる
• ストレージの選択肢は尐く、しかも
I/Oパフォーマンスが低いものが多い • 時間課金、リザーブドインスタンス、
スポットインスタンス等のAWSの特
• 思ったほど安くならなかった徴を活かした構成を作れば、安価な
構成を作ることができる

費用例 80万円/月 40万円/月


順次バッチ処理で計算していた処理が、データ量の増大で追いつけない時がある。
そこでAWSで一時的に処理能力を補い集中処理を実施

事例4: 短期間の集中処理

• 一時的なデータ増大で計算処理が追いつかな
くなった

• 足りない処理能力を補うためのサーバセット
をAWSに構築

計算の元計算結果を既 • AWS環境は、VPC（VirtualPrivateCloud）に
になる存DBサーバに構築し、既存DCとVPN接続することでセキュ
データを書き込みリティを確保
コピー
• AWS環境の保守運用はR3で実施（お客様の管
理対象は増えない）

• 処理残が落ち着けばいつでもAWS環境はやめ
られる


今まで小企業では初期投資が大きすぎ不可能だった規模のサービスもAWSなら
可能です

事例5: 小企業の新規サービスのプラットフォーム

立ちあげたいサービス従来のやり方だと

ユーザ数：数百からスタートして数十万を目指す • 小さなサーバ・回線でスタートすると急成長時に困る

データ量：開始してすぐ数十TBが予想される • 大きなサーバ・回線を用意するには資金が足りない

アクセス数：ユーザー数に依存 • サーバ管理のために人を採用するわけにもいかない

サーバ管理者:1人

AWSなら・・・

• 小さなサーバで開始して、成長してくればすぐに大きくできる

• 小さなうちは費用もさほどかからない

• 回線もサーバ規模に応じて自動的に追従して拡大していく

• サーバの監視、スケーリング、バックアップ等ほとんどのことを自動
化できるので管理者も尐くていい

• 万が一サービスから撤退することになっても、資産は残らない


サーバのコピーが簡単にできるので、顧客別の専用サービスが簡単に立ちあげられ
ます

事例6: 専用サービスを複数立ち上げていく

AWS コピーして構築 AWS コピーして構築 AWS

顧客データセンター顧客データセンター顧客データセンター

顧客B 顧客A 顧客C


最後にお知らせ・・・

社員募集中

上流から下流まで一気通貫でシステム開発したい人、
弊社で是非一緒にやりましょう

弊社と一緒にシステム開発したい協力会社さんも募
集中です

info@r3it.com まで


ありがとうございました


JAWS-UG三都物語_企業でのAWS導入のエントリーポイント

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie JAWS-UG三都物語_企業でのAWS導入のエントリーポイント

Ähnlich wie JAWS-UG三都物語_企業でのAWS導入のエントリーポイント (20)

Mehr von Toshiyuki Konparu

Mehr von Toshiyuki Konparu (20)

JAWS-UG三都物語_企業でのAWS導入のエントリーポイント