JAWS FESTA Kansai アンカンファレンスレポート 関西のおっちゃん/Oracle/クラウド時代のソフトウェアベンダー

はじめに

こんにちは植木和樹です。9月28日（土）に大阪 京セラドームで「JAWS FESTA Kansai」が開催されました。

当日、私は朝から夕方までずっとアンカンファレンス会場で各界を代表するモデレーターの方とたくさんの議論やアイデアを交わし、楽しく充実した一時を過ごさせてもらいました。本日は私が参加したアンカンファレンスの様子を手元のメモを元にまとめてみたいと思います。

本当は文章としてまとめてみたかったのですが、議論があらゆる方向に発展してはまた元の議論に戻ったりして、とても私の能力ではまとめあげることができませんでした。そこで会話風箇条書き形式にしてみることで、少しでも現場の臨場感をお伝えできればと思います。

早番：関西のおっちゃんの口説き方

金春利幸さん 関西のおっちゃんの口説き方

AWSの導入をお勧めするときに、地方によってお客様の反応に特色があります。関西に限らず地方によってどういう反応があるのか、全国で共通する反応にはどういったものがあるのか、その反応に対してどういう答えがあるのかをディスカッションしましょう。また、お客様だけでなく、すでにお客様にはりついているTraditional SIer とどうやって戦っていくのか、あたりもディスカッションしましょう

セキュリティ（情報漏えい）に対する抵抗感

PマークやISMSの外部監査についてはセキュリティコンサルタントのIT知識によってチェックのレベルが違う。
クラウドにデータを置くときにセキュリティとして気にしているのは2箇所。
1. 各事業所からデータセンターまでの「経路」の安全
2. データセンター内「サーバー自体」の安全。
「経路」の安全は「FireWall」「SSL」「VPN」で守られていると伝えると安心してもらえることが多い。
「FireWall」「SSL」「VPN」はクラウド特有の言葉でなくレンタルサーバー時代から10年近くかけて浸透してきたものだから安心してもらえる（身近な言葉）。
ネットワークの向こう側にデータを保存するという意味ではレンタルサーバーもクラウドも同じなのでは？
懸念の対象は技術的なものでなく「感覚的」なもの
レンタルサーバーは「国内大手ベンダーがやってるんだから大丈夫だろう」という安心感がある。

従量課金に対する抵抗感

• バースト（たとえ自サイトがバーストしなくても不安）
• 稟議を通すため月額固定が望ましい

「何に対して大きく課金されるのかが分からない！」
ディスク容量に対する課金はわずかだけど、データIO量に思いの外、多額の課金がかかる場合がある。
「海外にあるサーバーにお金を払うという抵抗」
「ドル払いという抵抗感」
円安になれば支払額は増加していく。
AWSが過去幾度となく料金改定で安くなった説明をしても抵抗感はあるようだ。
cloudpackさんとかserverworksさんが月額固定のフルマネージドサービスをやってる（クラスメソッドも支払代行サービスあり）ので、そういったサービスを利用してもらえれば安心してもらえるのでは？

クラウドの浸透度合い

正直低い。
経営層、営業層だけでなくITエンジニアでもクラウドがまだまだ知られていない。

企業にクラウドを提案しても、既存ベンダーのクラウドに対する無理解や嫌悪感で、感情的に抵抗してくるというケースもある。
特に根拠はなく「クラウドはあぶない」と不安を煽ってくる。
そういう時はどうする？
資料を用意して根拠を持って説明して、そういう既存ベンダーからのひっぺがしを行わなければならない！

無理解をどう解消する？勉強会やハンズオンをどんどん開催すれば解消するのか？
勉強会やハンズオンの集客具合は？
クラウドに興味がある人は自分でいろいろ勉強しているから、いまさら勉強会にはこない。
クラウドに興味のない人はそもそも勉強会を知らない。
関東との違いは勉強会の多さ？
勉強会が多い＝事例に触れる機会が多いということでは。
やはり身近な事例が必要では。どこかで使われたという事を聞けば、じゃぁ自分も覚えるかということになるかも。
地方は保守的
「先端技術の採用については2番目で良い」
「先進性よりも枯れて安定した技術を採用する」
そのための身近な事例。シンプルでいい、小さくていい（EC2とRDS1台ずつとか）。
とにかく多くの場所で使われているという事例を出していこう。（JAWS埼玉でも事例紹介は好評だった模様）
その地方を代表する企業で導入されれば一気に広まるのでは？
名古屋では6月のAWS Summitでトヨタが採用したので安心感が広まりつつある模様。（トヨタカレンダーというのを知りませんでした）
名古屋のように地方を代表する企業って他の地域にもあるの？
トヨタと名古屋の関係は特殊なケースかも。
他の地域では官公庁とか地方銀行とかの事例がでるのが望ましい。

まとめ：アンカンのキーワード

1. CSP（Cloud Sales Pattern）... 経営者・営業担当から頻繁に受ける質問への答え方や資料をまとめパターン化する
2. 身近な言葉で説明する
3. シンプルかつ有名企業の事例

中番：Hack Reduce Amazon RDS for Oracle Database powered by JPOUG

大島正樹さん と 渡部亮太さん Hack Reduce Amazon RDS for Oracle Database powered by JPOUG Oracle RAC on Amazon EC2を支える技術

Hack Reduce Amazon RDS for Oracle Database powered by JPOUG … 俺達のやりたいことができるのか ? 俺達の環境と「シームレスに機能」するのか ? できない? ならば こうしてしまえ!? Amazon RDS for Oracle Database を題材に熱く議論します。

Oracle RAC on Amazon EC2を支える技術 … Grid Infrastructureそして Oracle Databaseのクラスタ・インストールおよびデータベースの作成と利用を EC2で実現するポイントを紹介します。

Oracle RDS Mutl-AZの謎。

Multi-AZ構成でフェイルーオーバーさせた時のalert.logを確認してみた。
REDOログから普通にリカバリが行われてる。
REDOはマスターとスレーブで常に同期されてる？？？
まるでマスターとスレーブノードがSANストレージで繋がってるみたいな挙動をしてる。
MySQLのバイナリログを使ったフェイルーオーバーリカバリとは明らかに異なる挙動
Oracle RDSの内部情報が公開されていないから、これ以上は分からない。

スナップショットについて

マニュアルスナップショット実行時のalert.logを確認してみた。
普通にbegin backupend backupしてデータファイルをバックアップしてるっぽい。
素直な実装。

Oracle Enterprise Edtion

Oracle RDSは「Standard One」「Standard」「Enterprise Edition」の3種類。
Enterprise Editionはオンプレと同じ機能が使えるの？
「RAC（Real Application Cluster）」と「Data Guard」は使えない。
でも代表的なオプションの「パーティショニング」「圧縮（Advanced Compression ）」「暗号化（Advanced Security）」は使える。
それだけ使えれば充分じゃない？

RDSでRACはどうして使えないの？

RACのネットワークはサービス用のパブリックネットワークと、クラスターノード間のプライベートネットワークで構成する。
プライベートネットワーク間はブロードキャストとマルチキャストでハートビートを行っている。
AWSのネットワークではブロードキャストとマルチキャストが使えない。つまりハートビートが構成できないからRACが使えない。

オンプレからのデータ移行はどうする？

Data Pump推奨。
1. オンプレDBからダンプファイルをエクスポートする。
2. ダンプファイルをAWS上のEC2にコピーする
3. RDSにダンプファイルをインポートする。
データ移行に時間かかりすぎるんじゃない？その間ずっとサービス止めるの？
リアルタイムのレプリケーションは「GoldenGate」とか「QuestSharePlay」など商用ソフトを使う必要がある。
でもライセンス量が高い！
大規模データベースのAWS移行はクラウドSIerだけでなく、本職のデータベースエンジニアを参加させるべき。
ところでData PumpってどうやってEC2にインストールするの？
正規ライセンスを持っていれば「Oracle Software Derivery Cloud」からダウンロードできる。

Oracle監査ツールって使える？

アクアシステムズの「Audit Master」がRDSに対応している。

まとめ：アンカンのキーワード

• 意外に制限が少ない（パーティションも使えるよ）
• オンプレからの移行、データ移行がミソ
• Multi-AZの謎

遅番：クラウド時代のソフトウェアベンダーのあり方

小野和俊さん クラウド時代のソフトウェアベンダーのあり方

クラウドの時代に、これまでソフトウェアを開発・販売してきたISVはどのように対応していくのか？また、これから自分でソフトウェアベンダーを始めるなら、SaaS / PaaSでソフトウェアを提供するべきなのか、パッケージで提供するべきなのか。クラウド時代のライセンス体系はBYOLなのか従量課金なのか。エンドユーザー視点ではクラウド時代にどのようなソフトウェアがどのようなライセンス体系で求められるのか。AWSをはじめ、クラウドが急速に普及していく中で、ソフトウェアベンダーはどのようにあるべきなのかをベンダー、ユーザー双方の視点からディスカッションしましょう。

もしあなたが社長なら自社ソフトをクラウド化する？しない？

お題：自社のIT資産管理ツールをクラウド化すべきか？オンプレ向けのままいくべきか？その理由は？

結果

• クラウド化する：2.5人
• オンプレにする：1.5人

「0.5人」は機器→管理サーバーへの情報送信がプッシュ型ならクラウド、プル型（管理サーバーが取りに行く）ならオンプレという意見。
※あれ？参加者は5人いたはずなのに1人分足りない・・・

クラウド派の意見

• Amazon MarketPlaceにAMIを登録すれば、すぐに使えて試せる
• 保守・運用コストを削減できる（スケーリング、バージョンアップ、バックアップが容易）
• どこからでも見ることができる

オンプレ派の意見

• 社内機器からクラウド上サーバへの送信データが多い場合、通信コストが大きい
• ファイアウォールに穴を開ける必要がある（サーバーからクライアントへのプッシュ通知機能がある場合）
• 資産管理システムの類は企業の情シスがガッチリ要件定義と検証、キャパシティ・プランニングを行うだろうからクラウドの柔軟性という魅力が活かせない

現場でエイヤッと作ったツールが意外と使い勝手がよくて、パッケージ化されてるケースはどうなる？
パッケージといいながら導入先ごとにカスタマイズしているとAMI化は難しいのでは？
そういうのはパッケージソフトといわず「ソリューションウェア」といって区別する。
カスタマイズしているのではなく、半製品を導入先のニーズにあわせて組み立てるソフトウェア。
当然汎用的になってないし、レイヤーレベルの抽象化ができていないとRDS対応などで大きな設計変更を強いられることも。
ソリューションウェアはちゃんとパッケージ化しましょう。

マーケットプレイスの活用について

ソフトウェアベンダーの立場でいうと、正直あんまり盛り上がってない

マーケットプレイスの時間課金システムは、営業担当者に対するコミッション（目標額以上を売り上げた場合の報酬）を考え直す必要がある。
ある月に一気に売り上げていた額が、5年とか10年のスパンで回収されるようになると営業担当が十分な報酬を受け取る前に退職してしまっているかもしれない。

「BYOL（Bring Your Own License」という考え方が目から鱗という経営者は多い。
いままでのライセンスモデルをそのままクラウドに持っていけるということを知らない人も多いのでは。

「アプリケーション混在環境での導入が難しい」
1台のサーバーでWebサーバーとWAF（Web Application Firewall）を構成したいという要求を実現するのが難しい。
導入がインスタンス単位になるので、いろいろな機能を組み合わせたサーバーを作りたいなど、柔軟な組み合わせのが難しい。
アプライアンス的用途（ある用途専用のサーバー）での導入なら良い。
（1台のサーバーにいろいろなソフトウェアを組み合わせて使いたい場合は、Amazonのyumリポジトリから商用パッケージをインストールすることで課金できるような仕組みがあるとおもしろいんじゃないかなぁと思いました）

情シスがからむとクラウドにデータを置くことに対しての抵抗にあう。
意外と営業部直接だと提案がスンナリ通ったりも。
Salesforceとか、モロに情報漏えいしちゃいけない顧客情報なのにクラウドが活用されている。
ユースケースの差？信用の差？
トヨタや日本郵政といった大規模事例が公開されているという点も大きいかもしれない。

アンカンのキーワード

• クラウド向けソフトウェア開発
  • 既存ソフト持ち込み（レイヤーレベルの抽象化）
  • クラウド向けに作り直し
• クラウドでサービスするならシングルテナント？マルチテナント？
  • EC2インスタンスを分ける
  • Herokuのアカウントを分ける

まとめ

初めてアンカンファレンスというものに参加しました。アンカンファレンスってなんだろう？議論についていけるのかな？と不安な気持ちで参加したのですが心配無用でした。白熱した議論を交わすというよりも、知らないことを教えてもらって、答えてもらって、誰かがさらに疑問をだすと、ふとアイデアが閃いて、意見を言って、感想を言い合って・・・のように、ゆる〜いながらも一つのテーマに対してワイワイと意見を交わしながら、いつのまにか一つの合意ができあがったりする様子がおもしろかったです。コーヒーとお茶菓子をお供に話合ってもおもしろいかもしれないですね。

AWSはインフラ寄りの技術のため、今回のJAWS FESTAでもインフラ＆フロントエンド（Wordpress,HTML5）といったコラボ企画が多かったですが、いろいろなミドルウェアのユーザーグループと交流するのも楽しいかもなぁとJPOUG（Japan Oracle User Group）の方達と話をしていて感じました。その道のエキスパートの方達との会話は本当に刺激的でした。ApacheやMySQLのユーザーグループともぜひコラボしてみたいですね！