AWSとOracle Cloudのサービス比較
今、クラウドにするならどこ？
と聞いたら、情シス的には、ほぼ100％AWSと答える。なぜなら、情シスには技術力はあまりないので、みんなが使ってるやつに乗っかりたいからである。
ただ、そうはいかないケースもある。既存の取引先とか、今のインフラの環境とかもろもろの事情で、Oracleクラウドも検討せなあかんときもある。
さらに、コストメリットでいうと、AWSより安いってラリーが言い切ってるし、現にOracle DBの費用だけの勝負ならオラクルクラウドの方が安い気もする。
でもさ、AWSのあの機能はOracle Cloudにあるの？
という疑問。いや、そもそも情シスごときが使いこなせないサービスも山ほどあるんだけどさ、でも、やっぱり今の世の中AWSと比較しないと判断がしづらいよね。
というわけで、AWSの主なサービス・機能でOracleクラウドで対応するサービスを洗い出してみました。
| カテゴリー | サービス | AWS | Oracle Cloud |
|---|---|---|---|
| ストレージ | オブジェクトストレージ | S3 | Object Storage |
| 永続ストレージ | EBS | Block Volumes | |
| ファイルストレージ | Elastic File System | File Storage | |
| アーカイブ | Glacier | Archive Storage | |
| オンプレからのデータ転送 | Storage Gateway | Database Backup(oracleDBのみ) | |
| コンピューティング | 仮想OS | EC2 | Compute |
| サーバレス処理 | Lambda | ない。出ると噂 | |
| リソースの自動拡張 | Auto Scaling | Auto Scaling | |
| データベース | フルマネージドDB | RDS | Database Cloud Servis（DBCS) |
| KeyValueストア | DynamoDB | NoSQL Database Cloud Service*1 | |
| インメモリキャッシュ | Elastic Cache | Oracle Application Container Cloud Service(キャッシュ利用) | |
| DWH基盤 | Redshift | Database Exadata Cloud Service | |
| ネットワーク | 仮想プライベートクラウド | VPC | Virtual Cloud Network（VCN) |
| CDN | CloudFront | ない | |
| DNS | Route53 | DNS | |
| 専用線接続 | Direct Connect | FastConnect | |
| ロードバランサ | Elastic Load Balancing | Load Balancing | |
| 開発者ツール | ソースコントロール | CodeCommit | Developer Cloud Service |
| ビルドとテスト | CodeBuild | Developer Cloud Service | |
| デプロイ自動化 | CodeDeploy | Developer Cloud Service | |
| 管理者ツール | モニタリング | CloudWatch | Infrastructure Monitoring、Application Performance Monitoring |
| 構成管理ツール | CloudFormation、OpsWorks | Orchestration | |
| 分析 | MR | EMR | Big Data Cloud Service、Big Data SQL Cloud Service |
| ストリーミング | Kinesis | Event Hub | |
| メッセージング | メッセージキュー | SQS | Messaging |
| モバイル通知 | SNS | ない | |
| Eメール配信 | SES | Email Delivery*2 | |
| セキュリティ | ID管理 | IAM | Identity and Access Management(IAM) |
| ソフトウェア | マーケットプレイス | Marketplace | Marketplace |
| デスクトップ仮想化 | 仮想デスクトップ | Workspace | ない |
| アプリ配信 | AppStream | ない | |
| 移行 | データベース移行 | Database Migration Service | ない？ |
| サーバ移行 | Server Migration Service | Ravello Cloud Service |
第一印象としては、結構対応してきてるなぁという感じ。
実際使えるかどうかは別だが、急ピッチで機能追加もしており、Oracleの本気度は伝わってくる。
いや、でも、やっぱAWSがいいなぁ。
なお、これを調べて一番胸にぐっときたのは、Developer Cloud ServiceのCI機能として、ハドソンの名前があったこと。
誰か、もうやつを引退させてやってくれよ・・・。
iPhoneを企業導入することになってMDMとか運用管理とかやってみた
前提
- ユーザー企業の情シス
- 社員、店にiPhoneを配布することになった
- 社員配布数：100端末以上
- 店配布数：数百
- 検証のため、一部先行して導入
- iPhoneは、キャリアから調達（Docomo）
- キャリアのMDMサービスを使用（あんしんマネージャー）
全社展開に向けて、運用管理を考えなきゃ。
検証当初に困ったこと
- キャリア提供のMDMは機能不足な気が
そもそも、キャリアの提供するMDM機能ってイケてるのか？
色々調べた結果
キャリアの提供するMDMはイケてる
- あんしんマネージャーはVMWare社のAirWatchという製品を提供
- そもそもAppleが操作を許可してないことはMDMからも操作できない（iOSのアップデートは無効化できない）
- サポートは時間がかかるが丁寧で確実ではある
- アプリインストールの自動化はAppleが提供する企業向けプログラムとMDMを組み合わせれば実現可能
Appleが提供する企業向けプログラム
- Device Enrollment Program(DEP) ※AirWatch対応
- 端末の初期設定（キッティング）の自動化
- アプリ配布のサイレント・インストール、 iOSの更新。
- Volume Purchase Program(VPP) ※AirWatch対応
- 企業向けAppStore
- アプリライセンスの一括管理
- AppleIDをユーザーが意識せずにインストール可能
- Apple Developer Enterprise Program
- AppStore（VPP含む）通さずにアプリ配布が可能（自社サーバ経由）
- 開発ツールの提供やAppleのサポートがある
- 大企業でAppを内製してる企業向けなので不要
- AppleCare for Enterprise
- 企業向け端末保証。キャリアの保証があるので不要
Device Enrollment Program(DEP)
- 初期設定の自動化
- iPhoneを箱から出して、最初にやる設定作業を自動化できる。
- これがないとUSBでPCにつなげて設定する必要がある
- Apple Storeやキャリアから購入すると、端末にDEPの設定をした状態で出荷が可能
- 端末側でのプロファイルの削除の無効化が可能
- iPhoneを箱から出して、最初にやる設定作業を自動化できる。
- アプリの配布
- アプリのサイレントインストールが可能になる
- iOSの更新もできる
Docomoから購入する場合は、ある程度設定済みで納品されるので、効果は薄い（ZEROではない）
Volume Purchase Program(VPP)
- 企業向けAppStore
- 組織に対してライセンス数を購入する（有料無料問わず）
- 購入したライセンスを端末に摘要する
- 法人のクレジットカードが必要
- AppleIDをユーザーが意識せずにインストール可能
- インストール時にAppleIDのパスワードが入力不要 → ITリテラシーが低いとパスワード入力は意外とつまづく
- なぜか、パスワード２回入力が必要
- 電波の関係か、ちゃんとパスワード２回入力しても、インストールできないことも
- うちの会社では、初めてのアプリ配信では、20％しかアプリのインストールに成功せず
- プッシュ配信でのインストールだったので、失敗すると再度プッシュしてあげる必要がある（成功するまでプッシュを繰り返す毎日）
まとめ
- キャリアのMDMだけでも、運用管理は可能
- たまにちゃんと動かないこともある
- プロファイルでアプリ削除を無効にしたはずなのに、削除できちゃった
- 手動削除したら、アプリをプッシュできなくなっちゃった
iOSも結構な勢いでバージョンアップするので、MDM側もそれに追いつくのが大変。細かい不具合は許容するしかない。
まだ、うちも検証中だけど、スモールスタートして運用手順を確立してから全社に拡大していった方が良い。
なお、BYODで行う場合は、システム部門は下手にデバイス管理すると、結構死ねる気がする。使う側も個人端末に監視エージェントとか入れられるの嫌だろうし。そこは、端末を管理せずに、N/Wとアプリ側でうまいこと制限した方が得策な気が。
iisのアクセスログのtimeって開始時間か終了時間か？
ASP.NET Webforms アプリがあるのだが、このごろピーク時の性能劣化がひどくなってるとのことで、Zabbixでリソース監視したり、アクセスログなんかをBigQueryに突っ込んで原因を探ったりしていたのだが、iisのログのtime って、そもそも開始時間なのか、処理の終了時間なのかが気になった。
iisのログには、time-taken という処理時間（ミリ秒）が出力されるが、timeが、開始時間なのか、終了時間なのかでログの見方は変わってくる。
microsoftのサイトを見ると
とあるので、リクエストの開始時刻と思われるが、なんか腑に落ちないのでテストしてみた。
環境
OS：Windows2012R2 サーバ
iisバージョン：8.5
ログ形式 ：W3C
テスト方法
１．めっちゃ重いタイムアウトになる処理を投げる
２．アクセスログでどう記録されるか確認する。
今回は、17:10に処理を開始し、17:31にタイムアウトが発生した。
で、結果。
time：17:31
処理が終わった時間やん！
設定でここの挙動変えれるの？
というわけで、ちょっとハマった話。
