今日はノーチラス・テクノロジーズ主催の「業務システムにも、クラウドを」をテーマにしたノーチラスのクラウドサービス紹介セミナーに行って来ました。
ノーチラス・テクノロジーズとして主催するセミナーは実は初めてだったらしいです。 Cloud で基幹システムを使うというのはまだまだ制限がある中で、先駆者としてノーチラス・テクノロジーズが手がけた事例の紹介とノーチラス・テクノロジーズの新製品 Node0 シリーズの説明が行われました。
アジェンダは以下のようになっていました。
15:00〜15:10 開会の挨拶 アマゾン データ サービス ジャパン株式会社 パートナ・アライアンス本部 本部長 今野 芳弘氏
15:10〜15:50 西鉄ストア様の本部基幹システム移行事例 〜基幹システムの本格的なクラウド移行の裏側〜 代表取締役社長 神林 飛志氏
15:50〜16:30 アンデルセンサービス様 生産管理システム・EDIシステムの移行事例 〜必要な分だけ使うクラウド利用のあり方〜
16:40〜17:10 ノーチラスのクラウド（Node0 シリーズ紹介）〜 業務システムをクラウドへ 〜 代表取締役社長 神林 飛志氏
17:30〜18:00 Q&A
今日も最初にわたしの所感を書いておきます。
@okachimachiorz1 さんの歯に衣着せぬキレキレの Cloud に対する意見を聞けたのが大変ためになりました。とくに先日のガートナーの記事：ニュース - 「クラウド化の流れは近いうちに止まる」、ガートナーがITの近未来を予想：ITproに関しては、結論は一緒だったんですが、解釈の仕方がわたしと全く違っていた（より深かった）ので、とても目を開かれる思いをしました。
和製 Cloud に関してはケチョンケチョンな言われようでしたが、AWS 大絶賛というわけではなく、 Cloud についてのノーチラス・テクノロジーズの考え方を聞けたことが大変有用だったセミナーでした。
今日は、なるほど、と思うことや耳が痛いと思うことが多かったので、以降のノートではわたしがなるほど/耳が痛いと感じた部分を赤字にしておきたいと思います。
では以降よりがわたしのノートです。
15:00〜15:10 開会の挨拶 アマゾン データ サービス ジャパン株式会社 パートナ・アライアンス本部 本部長 今野 芳弘
- 開催会場は、Amazon Japan/ Amazon Web Service の本社。
- AWS は最近、活況。その中でもノーチラス・テクノロジーズは老舗として使ってもらっている。
- 去年から潮目が変わってきてEnterpriseで活用する事例が増えてきている。それの中でも中核がノーチラス・テクノロジーズさんで頼もしく思っている。
- AWS Summit が 6/5,6 に開催されますよ。
参考：AWS SUMMIT TOKYO 2013
15:10〜15:50 西鉄ストア様の本部基幹システム移行事例 〜基幹システムの本格的なクラウド移行の裏側〜 代表取締役社長 神林 飛志氏
西鉄ストア様は、Asakusa Framework/Hadoopによる本部基幹システムを、AWS上に構築しました。大規模基幹バッチ処理が、パブリッククラウドで実現する裏側をご紹介します。
株式会社ノーチラス・テクノロジーズ
結論からいうと簡単ではないです、非常に苦労しました。
➤ プロジェクトの外観
- 60人規模のプロジェクト。
- 売上、売掛金管理、買掛・未払い、リベート管理、テナント管理、人事、管理関係、棚卸
- とにかくてんこもり。
- 典型的なSI。本部バックエンドの勘定系すｂてと連動する情報系システム群。
- 基本的にノンストップ。
- 実はトラブルがありました。国内のCloudでやっていて止まってしまった。
➤ 事の起こり
- CGCグループで中規模小売業の共同利用基盤の開発
- 500億円規模の小売業があつまって自社のシステムの共同利用基盤をつくるというのがスタートだった
- 要件定義は数社が参加して行われた
- もともと単社ではむずかしかった
➤ 業務目的
- 基本的にバッチです。
- POSデータのクレンジング
- 債権の計上回収、請求ごとの名寄せ
- 仕入れ・費用計上の〆処理
＊
- 消費税処理
- 明細単位で処理する仕組みがなかったので、それをあらたに組む必要があった
＊
- テナント管理
- ここが日本でHadoop使っている中で最大規模だと思う
- 売上の確定処理
＊
- リベート管理
- 売価還元法管理会計
- 個別原価法管理会計
＊
- データ総量のうち管理会計が全体の1/3
➤ 背景と課題
- IFRS適用
- 売上管理から利益管理（コストを引かないといけないのでマッチングをしないといけなくなる）へ
- コンビニで水を買っても小売は利益が分からない
- 今の経済状況では必要なのは利益であって、売上ではない
＊
- 技術的な課題
- 計算量が膨大になる
- 現行の売価還元法はカテゴリーベースでの算出であり、かつ総額での計算である個別法での計算は、売価還元法と比べた場合、各単品の細かいトレースをとって計算するため、計算量が1,000倍になる
➤ スケジュールの進展
- 遅れに遅れました。
- 全面的に遅れたというわけではない。順次リリースを行ったので。
- 最終的なカットオーバーが遅れたということ
➤ 発生した課題
- 技術課題
- 画面系、JSでやったがパフォーマンスがでない
- バッチ系、一部SQLで書いたがまったく動かなかった、が、全面Asakusaに切り替える羽目になった
- PMも三回変わることになった
- コストを重視すぎて外注比率があがりすぎたのが問題だったと思っているとのこと
➤ 発生した課題
- パフォーマンス
- 特にバッチ処理がポイントになる
- 最初はRDBもつかっていたが、全面Hadoopに置き換えた
- Asakusaはこの西鉄さんようにつくられたようなもの
＊
以上の課題をどのように解決していったのか？↓
➤ ヘビーバッチ処理
- 売上、一億件/day
- 債権管理、900万件程度の集計処理
- 仕入れ、2,700万件の取り込みクレンジング処理
- 債務処理…
＊
- 全体のばっちスケジュールは8時間超にわたる。
- IOインテンシブなHadoopが8時間ぶっ通しで動き続けるということで、そこかしこでトラブルが起こった
➤ バッチ処理はそもそもどういう処理があるのか
- RDBMS
- SQLでバッチ記述
- スタンダードではあるが、パフォーマンスはでない
＊
- Hadoop〜Asakusa
- Hadoop はバッチは速い。そしてバッチ専用言語で誰でも書けるようになった。
- このバッチは3人で書いている
➤ Hadoopは本当に有効だったのか
- Full Outer Joinのとき、とくに圧倒的なパフォーマンス
- だいたい想定通りにパフォーマンスはでることが多い。
- フィットしないときのパフォーマンスは確実に落ちる。
- 既存のシステムとうまく連携できないときはパフォーマンスがでない
➤ 開発手法
- きちんと設計されていることが前提だけれども、Asakusaは圧倒的だった
- SQLから書きなおしを結果的に巻き取れた
＊
- SIでは総じて馬鹿をやるという前提をしくことが大事ということになった
- できないやつは書くな、足をひっぱるから
- いわゆるFool proofが非常に大事
- いろいろ試行錯誤させないことが重要
➤ SIの視点から
- デザインが大切
- データフローを設計できない人が多い
- データをつくるという基本的なことができない
＊
- SQL、Webの弊害
- 問い合わせはできるがそれでおしまい
- RDBMSはオプティマイザまかせだから
＊
- パフォーマンス・チューニングができない
- ボトルネックの発見ができない
＊
- バッチ処理については人材不足が否めない
- 業務系は残念ながらバッチ系が多い
➤ ユーザ視点から
- SI屋さんにまかえないほうがいいんじゃないですかね。
- 業務系のバッチ処理はビジネスロジックになる
- 自分で管理することが大事です
- そして、ちゃんとレビューすることが大事。
➤ インフラの課題
- 和製Cloudベンダーさんのインフラは高い
- 人員を食わせるためのDCという側面があるから
- 実態は2-3人で運営しているのに何十人も雇ってる
＊
- 結果として遅い
- ハードの投資回転率が低いから代謝が遅い
- 規模のメリットを享受できていない
＊
- メンテできない
- トラブルになるとなぜかベンダーにきいてみますと言われる
➤ 和製クラウドベンダーの実力不足
- AWSとただ張り合ってるだけ
- 単純にHWそろえました、ミドルいれましたというだけのサービサーが多い
＊
- Hadoop Clusterはまともな運用もできていない感じだった
- いうとおりにやるので教えて下さい、とか
＊
- クラウド技術は一人でどうにかなるレベルではない
- そして、いまだに和製EMRもない
➤ 和製クラウドで障害頻発
- そもそも高い
- パフォーマンス悪い
- サーバー落ちる
- Hadoopでバッチが止まる事態が起こる。どんだけ一気にノードが落ちたかわかるだろうか、と
＊
結局問題解決をNautilusがすることになったそして・・・
➤ AWSへの移行
- 1ヶ月で断行
- ノーチラス・テクノロジーズさんのエンジニアひとりで対応（エースエンジニア）
- 移行トラブル何回も起きたが、それもリカバーした
- 「・・・もう駄目だ」とか何回も思いました。
- ちょっと普通では無理
- （線表は引いたが、ダメだったらインテックにもどします、という前提でやった）
➤ AWSへの移行はてきせつだったか？
- 結論からいったら正解だった
- コストパフォーマンスがよかった
- 可用性が高い（一回あげたら落ちない）
ただし癖はある
＊
- サービス
- 必要なものがそろっている、EC2とS3は最強
- （逆にこの2つを徹底的に理解できないならAWSでSIはできない）
- あとはEMRとGlacierくらい
- ※西鉄さんはEMRは使ってない
➤ AWSのメリット
- コストではない
- ビッグデータ時代といいつつ、たくさんS3においたり、EC2をあげっぱなしにしたりすれば当然高くつく
- AWSは顧客のガバナンスに関与しない
➤ AWSの移行で何が一番苦労したのか？
- 残念ながらサポートが弱い
- トラブルが起きたら自分でどうにかしないといけない
- 内部が複雑な分だけ（おしえてくれないし）余計に手間がかかることがある
- SIが自分でどうにかするという問題じゃない
- その問題は原因がわかり対策をしましたが、守秘にふれるのでお知らせ出来ませんが普通にある
- なんだかよくわからないことが結構ある
- やはり障害対策をやっておかないといけない
- サービス全体がおちるということはないとおもうがDC単位でトラブルが発生する可能性がある
＊
- AWSはプロダクトサポートだと考えよう
＊
- 運用監視の実施
- デフォルトでサービスがないので、対策は必要
- siteRockさんを利用
参考：システム監視・運用管理のサイトロック株式会社
＊
- バックアップ・リカバリ必要
➤ AWS上でのアーキテクチャ
- 既存DCの環境をそっくりそのままAWSに移行した、そのためにいろいろ制約
- 1 から開発するのならばS3を中心にすべきところをEBSを使用せざるをえなかった
➤ 移行手順について
- メリットデメリットははっきりさせよう
- 以下は一般的なシステム移行と同様、当然のごとく配慮にいれる
- NW、データ移行
- 運用開始体制の開始
- C/O
➤ 西鉄プロジェクトでCloudの位置づけ
- かなりの必然性があった
- コストとパフォーマンス
- ガバナンスの獲得
- 可用性の担保
- 拡張性の担保（これは便利です）
- 本番環境をほぼ無数につくれます、と。そしてその保全が楽です
➤ 仮にAWSに移行してなかったら
- 多分、終わってない、失敗してた。
- 余計なお金がかかった
- 将来に禍根が残った
＊
- もはやノーリスクはない
➤ まとめ
- 西鉄プロジェクトが大規模・ミッションクリティカルでもAWS Cloud で動きますという先駆者的事例になった
- 前例がないという言い訳は効かなくなった
＊
- しかし、簡単なものではなかったので誤解しないでほしい
＊
- クラウドに上げるメリット
- 高可用性、拡張性の担保、ガバナンスの確保、最後にコストとパフォーマンス
＊
- 保守という目的でCloudに移行することは絶対におすすめしない
15:50〜16:30 アンデルセンサービス様 生産管理システム・EDIシステムの移行事例 〜必要な分だけ使うクラウド利用のあり方〜
アンデルセンサービス様は、生産管理システムとEDIシステムをクラウド上に構築しています。インフラを手元に置かずに、運用をノーチラスに委託することで、初期コストを抑えて短期間で構築し、運用の手間を最小限にした事例をご紹介します。
株式会社ノーチラス・テクノロジーズ 佐藤 義仁
- 本当に効果が出せるクラウドの使い方。1年半の会社のなかでも長い付き合いをしているアンデルセンサービスの事例の話。
参考：アンデルセンサービス | ANDERSEN GROUP - アンデルセングループ
➤ クラウド利用のあり方
➤ クラウドの利点（3つ）
- 使いたいときに使いたいリソースだけ使う
- しなやかなシステム構成が可能
- HWのメンテナンスが不要
＊
こまかく見ていくと、
- 使いたいときに使いたいリソースだけ使う
- 使った分だけ料金を払う
- しなやかなシステム構成が可能
- リソースの追加を瞬時に行える（EBSだったり）
- システムの成長にあわせてリソースを使える
- HWのメンテナンスが不要
- HWの面倒はクラウドがわが実施
- （とめずに部品の交換をするといったことはオンプレではなかなか難しいよね、と）
- 長寿命なシステムを実現可能
➤ クラウドがむいている2つの使い方
- その一
- 一定時間のみマシンパワーが必要な業務
- ようは、バッチ処理ということ、西鉄さんはまさにこのケースにハマった。
- 必要リソースの調達：
- オンプレだと
高コスト、必要なマシンスペックを見積もりにくい、HW増強は容易じゃない - Cloudなら
必要なときに必要なだけ、そしてあとから構成変更が容易
- その二
- 企業の土台となる寿命の長い業務、たとえばEDI
- 商取引の情報を企業間で電子的に交換する処理
- 一回動いてしまえばそんなに手間がかかるものではない、でも止まるとヤバイ！
- （本当はずっと同じものを使い続けたいし、続けられるもの）
- 必要リソースの調達：
- オンプレの場合、
長く使い続けたいが、SWよりもHWの寿命がくるトラブルのほとんどがHW障害 - Cloudだったら
HWが不要、HWのメンテナンスが不要
- オンプレの場合、
➤ 事例の紹介 / アンデルセンサービスの事例
➤ 生産管理システム
- 一定時間マシンパワーが必要となる業務の事例
＊
- 原材料の調達先を変更したら具体的にどのくらい製品原価が変わる？（311の影響があったり）
- 既存バッチが4時間かかり、すぐにシミュレーションができない（いまもっているマシンスペックでは）
＊
- 生産管理システム構築の主な内容
- 1.分散バッチ処理環境 と 2.生産管理システム環境
＊
- 分散バッチ処理環境
- 既存バッチの高速化、それを低コストで
- 解決策：
- AWSクラウド環境を採用
- Cloudに適したアーキテクチャに変更（HadoopとAsakusa）
- クラウドを使った分散処理環境の利点は？
- 必要なときだけ利用、バッチ開始終了でリソースを追加・開放（バッチ処理を行うときだけお金がかかる）
- そして、当初必要なリソースでのスモールスタートを実現できている
- データ量増加にともなうリソース増強への対応が容易になった
- そして Asakusa/Hadoop でのバッチ実行結果は、4時間のバッチが20分へ
- 内訳としては
- Clusterの起動と停止（4分）
- データの送受信（5分ほど）数GBだから
- 実際の計算（12分）
- 生産管理システム環境
- 分散バッチ処理結果をもとに「見える化」を実施
- 解決策：
- 基幹システムの必要なデータをCloudに集約
- 集計処理は分散バッチ処理環境で実行
- 集計結果はAWS上のDBサーバに集積して高可用性を実現
- Cloudの拡張性を利用して、専用のWebアプリケーションを平易に構築
- お客様のコンピュータからWebブラウザで参照
- 生産管理システムの概要
- 材料投入実績と理論使用量の見える化
- 差異分析による、数量・価格差異の把握
- いずれも計算量が多い
- 生産管理システム導入の効果
- 業務上の意思決定がすみやかに（4時間が20分に）
- サーバコストは利用時のみ
- サーバのリソース追加が動的にできるように
- 機能拡張する際の開発における初期投資を最小限に抑えることができた
- 解決策：
➤ EDI
- 企業の土台となる寿命の長い業務の事例
＊
- EDI（流通BMS）の導入事例
- JCA手順では実現し得なかったトレーサビリティ基盤の強化
- 取引先企業との個別対応のシステム開発の課題に対する解決策
↓ - 2ヶ月で開発
- 「UJX」を採用してもらい、信頼性の高いシステムを短期間で実装
＊
- 調達がわでも流通BMSの導入へ
- 受注業務の流通BMS化は進んできている
- それを発注業務にも適用して行きたい
- 原材料メーカーへの発注業務はデータ化すら難しい状態だった（FAXをいまだに使ってたり）
＊
- 流通BMSシステムのリプレース
- リプレースのトリガーはHWの老朽化
- リプレース案：
- 専用のHW,SWを準備（オンプレ）→保守が大変
- ASPの利用→値段があがっても抵抗できない、ガバナンスとか維持不可能
↓ - ここでCloudの出番です、となった
＊
- クラウドを利用したEDIシステム構築
- 1. SWの寿命を最大限に活かせるシステム構築
- 2. トラブルに強いシステム構築
- HWがメンテナンスフリーに
- Cloudに特化した外部の運用監視サービスを採用した
＊
- EDIシステム導入の効果
- 業務が流通BMSで回るようになってきている
- コスト削減にも効果あり
- DCへの流通BMSサーバーのハウジングの必要なし
- パフォーマンス低下に対するスケールアップの容易性も担保した
➤ まとめ
- 生産管理システム
- 必要なときに必要な分だけ
- 利用料金は動かしている時だけ
- 機能拡張容易
- EDIシステム
- HWフリーな運用が可能
- すでに確立した業務ノウハウを活かせた
- 現実的なコストでHA
➤ 画面イメージの紹介
- 集計結果表示機能
- 理論との原価差異をみることができる
16:40〜17:10 ノーチラスのクラウド（Node0 シリーズ紹介）〜 業務システムをクラウドへ 〜 代表取締役社長 神林 飛志氏
ノーチラスとして、基幹システムをクラウド上に移行し、運用する道具立てをそろえたクラウドサービス、「Node0 シリーズ」の提供を開始いたします。本講演で「Node0」の各種サービスの全貌が明らかになります。
株式会社ノーチラス・テクノロジーズ
- IT ガバナンスのためのクラウド。考え方を紹介したい。
➤ Cloud化は進行しないのか？
- ガートナーがITの近未来を予想。止まる
参考：ニュース - 「クラウド化の流れは近いうちに止まる」、ガートナーがITの近未来を予想：ITpro - いや、そもそもみなさん使ってるんですか？
➤ 本当の意味でのCloudの再認識の時期なんじゃないか？
- 単なる仮想化をもってCloudというのは違うよね、当たり前だけど
- ミッションクリティカルなものがあがるのが、Cloud でしょう、と。
- それにたるものがいままであったのか？ 偽 Cloud が乱立してしまっているのが今。
- バブルが普通にもどるだけ、そういう意味ではガートナーが言ってることは正しい。
➤ Cloudの是非の前提としての地上戦
- SI屋さんの袋小路状態〜SIが瀕死の状態
- IT技術の高度化、複雑化
- 分散処理は普通になっていく
- それに対してSI屋としての対応ができていない
- SIGMODに論文通せているエンジニアの数をみればわかる。
- 日本はIT後進国だと自覚せよ
- 地上戦は壊滅しつつある
➤ SIが臨終すると何が困るのか？
- ノーリスク時代は終焉した
- 約束した時間、お金で終了するプロジェクトは皆無。
＊
- 自分でシステムをある程度、企画・開発・運用していく時代になるだろう
- アメリカ型のビジネスにSIが吸収されていく
＊
- ITガバナンスの確保が最低条件
➤ 結局、自分でがんばるためのCloud
- 自力でシステムを維持するためには、全方位で対応しないといけないが・・・
＊
- コストがかかる
- 人手の確保
- 運用にはお金を割り振れなくなる
＊
- そして、生き残るためにCloudを活用するとなる
➤ ではCloud化しないという選択肢は？
- HWは値上がりする
- なぜなら垂直統合であげたほうがDCにはいりやすい
- 最近はOracleにしてもどこもだすのはアプライアンスでしょう？
- もうCloudベースの考え方になっているということですよ
＊
- 結果として、オンプレはコストがあがる
- Cloudは値下がりするという流れになる
＊
- 今度はCloudベンダーにのどもとをおさえられることになるのだが、だからこそ、どうやってそこにのるのか？が大事になってくる
➤ Cloud化できるものとできないもの
- まずはガバナンスをはっきりとることをしたうえで！
＊
- Cloud化できるもの
- 基本的に外部のDCに預けられるものは全部大丈夫
＊
- それでもCloud化できないもの
- オンプレのコストがあがっても維持しなければならないもの
- 情報の外部流出が企業の存亡にかかわるもの
- NW断絶が致命傷になるもの
- 当局のご指導があるもの
- オンプレのコストがあがっても維持しなければならないもの
➤ その解決案としてのNode0のコンセプト
- Node0 DBR
- Node0 EDI
- Node0 UC
➤ Node0 DBR
- もともとの背景は、Asakusa Enterprise Support のビジネス課題
- POCがそんな簡単にできない
↑- Hadoop をマスターしないといかん
- そもそも分散環境は手にはいりにくい(2台じゃできないよ？)
- POCがそんな簡単にできない
＊
- Node0 DBR は自分でバッチを書くための環境
- バッチ処理を記述するためには？
- まず、設計・実装に集中する必要がある
- インフラは高速であればそれでよい
- バッチ処理が必要なときだけ資源をCloud上から借りればいいという考え方
＊
- 結局、Hadoopは自分で運用できないよね
- 障害発生したら、障害ノードをディスパッチするのが現実
- しかし復旧させたら普通に動く、がザラにある
- バグがよくわからない
- じゃあ、どこに任せるのか？
- とにかく安定しているCloudベンダー
- そして、Amazonがダントツ、なぜならAmazon自身が使ってる（商品マスタのクレンジングに使ってる基幹系に）
＊
- Upload & Run で Node0 DBR は使える
- 完全にラッピングするようにしました
- アプリケーションをUploadしたらあとは実行するだけ
- DeployまでCloud上で全部やってしまう
＊
- 開発環境
- IDE
- 実績の多いEclipseベース
- Node0 DBR とシームレスに連携
- データロードの仕組みも準備、Workbench（S3の指定した場所にデータをあげる）
＊
- レポーティング、これがキモ
- ボトルネックがどこかをみられるようになっている
- これはOSSではないので Asakusa には含まれていない
＊
- HadoopとAmazonを意識する必要がない、Batch process as a Service のようなものだとおもってくれればいい
➤ 今後のバッチ処理のありかた
- とにかく自分で書け
- 書けなくても自分で設計しなさい
＊
- 古いバッチはメンテできていない実態を認識すること
- 同じ轍を踏んではいけない
＊
- これは開発方法論とかではない
- そもそもITの話ではない
- ITのドキュメントはWhyを書かない
- コンピュータに理由を説明する必要がないから。そういったものをこそ残すようにしよう
➤ Node0 EDI
- EDI は日本はもっと誇っていい、むしろ過剰にオーバースペック。
- 日本はやっぱりある意味バカ。
- 全部のデータをトレーサブルなのは日本だけ。
- でも、かなり普及している、それなりに要求水準も高い。
＊
- とはいえ、いろんあところからはしごを外しにかかってきている現状もある
- そもそもミションクリティカルなことも仇になってる
- ノンストップが基本、落ちると業務に致命傷、そして安全第一
- 安全第一で長く使いたいというニーズがハード供給と一致しない
＊
- Cloud化はなので、むしろ必然
＊
- 背景その一
- Cloudの特徴とEDIの要請
- 可用性が普通に高くて、HWフリーに対して、HW寿命＜EDIシステムの寿命、高可用性を安くほしい
- 背景その二
- その一方でパッケージビジネスの終焉
- ライセンス体系が破綻をきたしてきている（メニーコアで迷走がはじまった）
＊
- Cloud時代の「ライセンス問題」
- しょうがないから従量課金になる
- しかしユーザにとっては「規模の経済の破棄」
- つまり投資ではない、したがってレバレッジが当然きかない
＊
- 環境が可変な場合は、従来のオンプレが前提のライセンス体系は正当性がなくなる（CPU数？仮想環境？必要なときだけ使う？…）
- どうかんがえても従来の考え方では無理がある（現場の営業も判断できない）
＊
- というわけでNautilusではむしろCloudを基本にそえました
- On Cloud/Off Cloud という体系にした
- 単一のクラウドがやばくなったときに逃げられるライセンスが重要と考えました、と。
- オンプレ緊急回避/別Cloudに移転できます、ASP型では脱出可能です、と。
＊
- Node0 EDI詳細
- Client、ユニークです、Cloudにのってます。Clientだけど高可用性が必要だから
- For Service、OEM供給型の「環境まるごと」の提供
＊
- 今後はシステムの新陳代謝についていくのはオンプレでは困難。
➤ Node0 UC
- 背景
- さいきん、とりあえずCloudにあげろ、といってくるお客さんが多い。
- Enterpriseは一度あがるとどんどん進行する。そして西鉄さんのような超ヘビー級をCloudにあげるはめになった。
＊
- 自社の資産を保護するためにCloud化するためのツールが Node0 UC
- Cloudは高可用性だ、という現実。
- Cloudは最初からマルチDCが基本になるので、DRのあり方が変貌しつつある
＊
- 業務系システムのCloud化メニュー
- アドバイザリー、基盤提供、そしてサポートの提供
➤ まとめ
- Node0シリーズ、共通の思想
- ユーザガバナンスの確保のためのCloud基盤
- システムの資産性をあげて投資可搬性、永続性をあげる
17:10〜17:30 AWS のサービス紹介（仮）アマゾン データ サービス ジャパン株式会社 エコシステムソリューションアーキテクト 松本 大樹
➤ AWS の様々サービスの紹介
- EC2, S3, Glacier, EMR, RDS, VPC を紹介。
➤ AWS をEnterpriseに使う3つのメリット
- 冗長性/拡張性
- セキュリティ(AWS GovCloud を例に)
- レポート、認定、第三者認証(SOC1,2,3 report)
- コスト
- 実際に使った時だけ支払うというスタイルを徹底出来れば
17:30〜18:00 Q&A
➤ Java, RAC をAWSで置き換えられるか？
− Java は問題なく動く。
− Oracle RAC は現状は動かない。共有ディスクが使えないという技術的な問題。
− RAC でなければならない理由次第で載せ替えることはもちろん可能。
− RAC はどうしてもはずせないというお客さんの場合、Direct Connect を使って RAC はオンプレにおいて AWS から接続して使うという使い方をしているところもある。
ノートは以上です、では今日はこんなところで。
