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/

自己紹介

【名前】金春利幸（こんぱるとしゆき）珍しい名字ですが・・・ご存知の方は、能楽の金春流をご存知かと・・・

【お仕事】アールスリーインスティテュート Founder & Manager

• 普段はプロジェクト・マネジメントと上流工程を担当• 社外および社内でのAWS導入の先鋒を担当

Tips! 銀座に金春通りという通りがあったりします

【好きなAWSサービス】Route53

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

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

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

インフラ

ＯＳ

ミドルウェア

アプリケーション

Windows

Android

など

各種DB、APS、フレームワークなど

各種サーバ

ホスティングハウジング

法人向けサービス・業務系システム・対消費者システム

・工場系、機器制御系システム・研究サポートシステム・各種コンサルティング

調査業務分析

システム要件定義

仕様・開発テスト

導入運用・保守

トータルサービス

・業務分析、業務の「見える」化・データ分析・システム企画・全社内システムの最適構成設計・現行システム評価・パッケージソフト評価・ＩＴコンサルティング

ファンクショナル・サービス・システム開発

・フレームワーク設計・プロトタイプ開発・ベンダーマネジメント・クラウド化・サーバ冗長構成設計・ユーザテスト代行・業務マニュアル作成・他社製品導入・現場教育・メンテ運用設計

・システム保守・ＩＴ全般サポート・技術的ＱＡ・現行システムのドキュメント化・ＰＧトレーニング

AWSを利用

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

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

AWS本格導入のきっかけは、3.11 でした・・・

3.11 弊社社員が仕事で仙台にいました（私も関与しているプロジェクトでしたがたまたま私は行ってなかった）

関西からは尐し遠くのことと思っている方も多いようですが・・・

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

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

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

① 山形から仙台へタクシーを向かわせる

② 仙台から山形空港へタクシーで

③ 山形空港から伊丹空港へ

弊社とAWSの関わり

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

とても便利ということで・・・

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

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

2012.12 AWSパートナーに登録

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

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

・・

弊社自身のAWSの使い方

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

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

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

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

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

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

弊社自身のAWSの使い方

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

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

クラウドに対する妄想

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

• クラウドだからサーバ壊れないんでしょ？

壊れる。壊れる前提で設計する。ただし、壊れても大丈夫にする術が簡単

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

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

• クラウドだから安いんでしょ？

概ね合ってるが場合による。ただ安くするための手段がたくさんある

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

事例1: 月に一定の期間しか利用しないシステムの構築

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

• 月末・月初の締日前後にしか利用しない請求書処理システム（締日前後5日、日中8時間だけ利用できればよい）

• 多尐のダウンタイムは許容できるが動いているべきときは確実に動いていて欲しい

• とはいえ、サーバに対して面倒な運用作業はしたくない

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

• AWSならスクリプトを書いてAPIを呼ぶことでマシンの起動も停止も自動的に思いのままできる

• 止めている間はほとんど課金されない

• 稼働期間中は、しっかり監視する仕組みにすることで動くべきときに確実に動いているという仕組みを構築できる

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

AWSでの構築のメリット

事例2：製造業でのAWS導入

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

生産上の様々なデータをタブレット端末で入力し、 AWS 上のサーバへ送信

本社でリアルタイムに生産状況を把握・分析

• 実験的プロジェクトでもIT部門を通すと全社インフラが・・・等で頓挫してしまうことがある。AWSを使って全社インフラとは無関係に構築すれば、スムーズに実験できる

• 製造業へのシステム導入はラインの邪魔をしないようにスモールスタートで実験を繰り返していく必要があるためいきなり大きなサーバは用意できないがAWSならスモールスタートできる

• 対応工場の増加に伴い、サーバをスケールアップ・アウトさせやすい

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

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

AWSでの構築のメリット

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

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

プライベートクラウド AWS

• 契約し確保したリソースの範囲内でサーバを構築しないといけない（サーバ間でリソースの取り合いになる）

• 一時的にテストサーバを増やしたいと思っても、リソースが足りないとできない

• サーバを追加を依頼しても数営業日かかったりする

• ストレージの選択肢は尐く、しかもI/Oパフォーマンスが低いものが多い

• 思ったほど安くならなかった

• リソースはほぼ無限にあると思っていい

• 使いたいときに使いたいだけサーバを使える。不要になればいつでも消すことができる

• サーバの追加は数分でできる。（自動的にもできる）

• ストレージのI/Oパフォーマンスを自由に指定できる

• 時間課金、リザーブドインスタンス、スポットインスタンス等のAWSの特徴を活かした構成を作れば、安価な構成を作ることができる

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

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

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

計算の元になるデータをコピー

計算結果を既存DBサーバに書き込み

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

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

• AWS環境は、VPC（VirtualPrivateCloud）に構築し、既存DCとVPN接続することでセキュリティを確保

• AWS環境の保守運用はR3で実施（お客様の管理対象は増えない）

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

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

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

ユーザ数：数百からスタートして数十万を目指す

データ量：開始してすぐ数十TBが予想される

アクセス数：ユーザー数に依存

サーバ管理者:1人

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

• 小さなサーバ・回線でスタートすると急成長時に困る

• 大きなサーバ・回線を用意するには資金が足りない

• サーバ管理のために人を採用するわけにもいかない

AWSなら・・・

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

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

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

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

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

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

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

顧客B

顧客データセンター

顧客A

顧客C

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

社員募集中

最後にお知らせ・・・

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

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

info@r3it.com まで

ありがとうございました

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

Documents

jaws ug hiroshima-20150221

JAWS-UG saitama-vol3-20140222

JAWS-UG大分 20151102

運用の価値とロールモデル - JPNIC · jaws-ug cli専門支部支部長 jaws-ug アーキテクチャ専門支部運営 jaws-ug ai支部運営 x-tech jaws 運営活動の場

jaws ug-kansai_lt_141202

JAWS-UGの紹介 (2013-02-08 JAWS-UG 東京第15回勉強会)

JAWS-UG CLI #07 VPC

20150523 operation jaws(JAWS-UG OSAKA #13)

jaws-ug kansai-special_kinesis_20150207

2012 jaws ug紹介(熊本ug版)

JAWS-UG Osaka 2014 Plan

アカウントのセキュリティ (第13回JAWS-UG札幌)

JAWS-UG Aomori #0 LT

20160726 jaws ug osaka-kansai_girls_firstattack

Jaws ug shimane-1

エンジニアリング/運用組織の行動モデル · 2019-12-10 · jaws-ug cli専門支部支部長 jaws-ug アーキテクチャ専門支部運営 jaws-ug ai支部運営

20160727 jaws ug-kobe_short_speak_alexa

20160608 JAWS-UG磐田

JAWS-UG ◯◯◯の紹介

JAWS-UG Tokyo SAP