Developers.IO 2018に参加した。その際のメモ。

「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 濱田孝治氏

「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 #cmdevio2018

すべて記事にわかりやすく記載されているが、せっかく書いたので、、メモを残しておく。

コンテナジャーニーのススメ

・コンテナ = dockerという前提での発表
・導入にあたり様々な障壁がある
　導入時に考えるべきは、アプリケーション開発と運用すべて
・スムーズな導入のためにもコンテナジャーニーを提案する
・最初に一人で利用してみる。手始めにPandocの利用(document変換ができる)がオススメ
・テストツールのイメージ化から進めるとよいかも

どこにイメージをおくか

・Docker Hub：無料で1つプライベートイメージを保持可能
・Docker Hub はパブリックだから使えない場合は、ECRを使おう！(逆にパブリック公開はできない)
・IAM制御するため、特定のユーザだけはアップロード可能、その他はダウンロードのみなど運用がよさそう

どこで実行するか

・Fargateを利用すると、コンソールからEC2が全く見えなくなる。EKSとはまだ連携できない

Fargate 注意点

・設定は環境変数に。DB接続先などは外から与えないといけない
・ログはバッファリングしない。標準出力するようにする
・ログドライバはawslogsしかない(標準ではCloud Watch Logsのみ)

その他

・Subversionだとしてもフック機能を利用して、Gitにコミットするようにすればうまくいくかも
・コンテナのセキュリティを検査するツールが多々ある

基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」 梶浩幸氏

#cmdevio2018 基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」で登壇しました。

・EC2へ固定IPアドレスを利用すると、CloudFormationで問題が発生することがある
・VPC作成時に暗黙的にルーターが1つ作成される
　・subnetから別subnetにアクセスする際にこのルーターを経由する
・経路はルートテーブルで設定する
　・ネットワークACLはこのルーターとsubnetの間のFirewallのイメージ
・VPC PeeringのMTUサイズは1500byteのみ
・NLBは1アーム構成(戻りバケットはNLBを経由せず、EC2が直接クライアントと通信する)
・NLBを利用したPrivateLinkは他社と連携しやすお(IPアドレス形態が重複しても良い)

いつでもどこでもオフィスになる魔法の仕組みWorkSpaces 豊崎隆氏

Developers.IO 2018 で「いつでもどこでもオフィスになる魔法の仕組みWorkSpaces」を話しました #cmdevio2018

・WorkSpacesはAWSのVDI(サーバ上のデスクトップ環境を提供する基盤のこと)
・ChromeBookから利用すると、キーマッピングがうまくいかないらしい(半角・全角が機能しない？)
・4172ポートで通信する
・満員電車から解放される！
・リモートワークするときは、BYODや働き手のパフォーマンスが向上するルールを検討しなければならない

WorkSpacesの利用を制限することができる

・MFA
・送信元IPアドレス
・デバイス認証(クライアントへ証明書をインストール)
・グループポリシーでの制御

費用

・Windows10で1台月額43ドル
・Office+セキュリティソフトで月額15ドル

ライセンス持ち込み

・OSのライセンスを持ち込む場合、4ドル値引きされるが、制約が多々ある
　・Didicated Instance利用必須
　・最低200WorkSpacesなど

運用について

・AZ障害が発生したときに、余計にIPを消費するため、ネットワークのIP数は余裕を持って設計したほうがよい
・WorkSpaces Application Manager(東京リージョン利用不可)に期待
　アプリケーションを配布することが可能

知って備えれば怖くない！ AWS移行ガイド 加藤諒

Developers.IO 2018 で「知って備えれば怖くない!AWS移行ガイド」を話しました #cmdevio2018

・移行チームを作る際に、ベンダーで悩むことがあるかもしれない
　その場合は1社であることにこだわらず、適切な箇所に適切なベンダを利用したほうが良い

DevOps:変化の激しい環境でビジネス競争力を向上させる具体的な方法 藤村新氏

Developers.IO 2018 で「DevOps:変化の激しい環境でビジネス競争力を向上させる具体的な方法」を話しました #cmdevio2018

・DevOpsという言葉がずるいと感じている
・最初は「Dev vs Ops ではなく仲良くしましょう」であったが、その後さまざまな解釈がある(明確な定義がない)
・アジャイルやツールなどさまざまなものでDevOpsが成り立っており、すべての成功はDevOpsが理由とされているためずるいと感じる
・クラスメソッドのDevOpsサービスの目的はビジネス競争力の向上
・ビジネス競争力を向上させる具体的な方法(リードタイムを短くする)
　→VSMを実行して、ボトルネックを排除していく

MANABIYA #2 – teratail developer days –を閲覧した。
YouTubeで配信されていたため、閲覧した。その際のメモ。

3限目 (13:30 – 14:10)：【2-3】Web × AI

・カーソルやタップの動きやスマホの傾きをよみ、特定コンテンツを先読みすることは実装されている。
　例えばGoogleマップは下に動かすとその先を読み込む。

・ブラウザに実装されると嬉しい。
　2012年にはXboxでユーザの動きを予想して、パケットを先送りをしていた。
　ゲームや動画配信のほうが先送り技術が多い。

・学習モデルを作成することはWEBでは費用対効果でのメリットが少ないため
　マイクロソフトが学習モデルを用意するサービスも用意している。

・Sketch2Codeを利用するとワイヤーフレームからHTMLページを作成できる。
　マイクロソフトの方針として、AIで人を置き換えるではなく、AIで人のめんどくさをなくすアプローチをしている。

・Adobe Senseiは被写体をくり抜くなどを実施でき、裏ではマイクロソフトのAIが動作している。

・マイクロソフトはGitHubを買収したため、そのコードを解析している。
　IntelliCodeというプラグインは解析結果をもとによいコードがかけるよう支援する。

・アミューズメントパークでは笑顔かどうか判定して、満足度を測るなども可能に。

無線LANことはじめを聞いた。その際のメモ。

Wi-Fiについて

・Wi-Fi：親しみやすくするため認知度をあげるための名称。登録商標
・今後は専用ロゴを使って、どのWi-Fi規格で通信するかを視覚化していく流れ
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-wi-fi-6
・CSMA/CD：昔は1つの同軸ケーブルでホストがつながっており、その際のコリジョンを防ぐための技術
　(コリジョンは電圧が重なり、範囲外になることで検知する)
・無線はCSMA/CAを利用しており、有線と無線の大きな違い

W52,53,56

・W52/W53は屋外では利用できない
・W53/W56の場合レーダー波を検知すると強制的にチャネルが変更される
　・電波送出時に1分間はレーダ受信有無を確認するため使用ができない(救急車が車道優先されるイメージ)
　・気象レーダーや空港の近くや海沿いで発生しやすい

事前サーベイ

・ネットワークを事前に調査してヒートマップを作る
http://www.ikeriri.ne.jp/develop/sitesurvey/index.html
・サーベイの際の閾値について、一般的な無線LANは60-75dbあればいいらしい

PoEがLANケーブルのどこ芯を利用しているか

・1000BASE-Tでは8芯すべてを信号線として用いている。
　このため、ギガビットハブにPoE対応機器をつなぐとリンクアップしなかったり速度が遅くなってしまう場合がある。
　そのような場合は100BASE-TXのハブにつなぎかえるか、1,2,3,6ピンのみ結線されている4芯のみのケーブルを用いるとよい。

AWS Systems Managerのススメを聞いたので、メモする。

前準備

・EC2インスタンスへのIAMロール(AmazonEC2RoleforSSM)が必要
・SSM Agentが必要
　・最新のAMIにはインストール済、なければ手動で
　・サポート対象：Ubuntuは12.04LTSから
・インターネットのアウトバウンド通信
　・もしくはSSM・EC2・EC2Message・S3へのエンドポイント通信が可能なこと
・SSM自体の金額は無料

できること

・パラメーターを保存する
　・環境ごとに異なるデータを保存可能
・RunCommand
　・コマンドを実行する
・Autometion
　・起動→パッチ適用→AMI作成→停止などが可能
・ステートマネージャー
　・スケジュールでRunCommandを実行する
・Maintenance Windows
　・Lambdaなどを実行することができる(理解しきれなかった)
・セッションマネージャー
　・ブラウザでシェルを実行することが可能
・インベントリ
　・定期的にサーバの情報を取得する

ベストプラクティスなど

・踏み台が必要だったサーバに直接対応できる
・スクリプト実行はSSMを利用したほうが、スクリプトの管理が容易になる
・IAMを利用して利用可能な時間に制限を設けることができる
・コマンド実行結果(lsなど)が遅かったりすることがあるらしい

クラウドは次の時代へ。これからのマルチクラウドを４人のスピーカーが語り尽くすへ参加した。その際のメモ。

ビックデータ分析基盤の成長の軌跡 – 白子 佳孝氏

・クライアント(リクルートと契約した企業)とユーザを結びつけるマッチングプラットフォームを開発している

・Mirror-Redshift
　・金曜日の夜にスナップショットをとり、そこからクラスターを作りデータ鮮度を求めない分析をするようにしていた
・2017年にBigQueryの導入によって、大規模に環境が変わった
　・データやユーザが増えても性能劣化が起きない、キャパブラ不要なDWHに乗り換える流れに

・今後やりたいこと

クラウドに関わる営業の本音、クラウドサービスの使い分け – 蔦野 岳人氏

オラクルとOracle Cloudについて

・オラクルは今大きな変革の中にある
　売り物がON-PREMISEからCLOUDへ
・Oracle Cloudはオンプレミスからクラウドへの完全互換性を謳っている
・ボトルネックを排除したアーキテクチャが売り
　元Amazonの人間とGoogleの人間が作っている
・IaaSでは低コストに力を入れている

今後営業に必要なマインドセット

・薄利多売のビジネスであることを理解すること
・クラウドは小さく入り込んで、大きく育てる
・営業先は情シスだけでなく、他部署へのアプローチも可能

マルチクラウドについて

・メリットはテクノロジーのいいとこどり、デメリットは運用の複雑化

シャドーITへの対策として -CASB-

・防いだ事例
　・Dropboxの私物利用
　・転職にあたり顧客データの持ち出し
　・インスタンスを起動して、コインマイニング

少し違った目線で考える、マルチクラウドのメリット、デメリット – 山田 雄氏

・ビールを奢れば、データ基盤の相談に乗ってくれるらしい

81

・81％ – クラウドを使っている企業がマルチクラウドである割合
・ActiveDirectoryやG Suiteなどを利用しているとマルチクラウドとしており
　なぜかマルチプライベートも入っているため割合が高め

各クラウドベンダーの姿勢

・AWSは否定派かも。CEOのインタビューから、複数のシステムの学習コストがかかる
　ボリュームディスカウントを考えると1つのほうがよい
・GCPはマルチクラウド、ハイブリッドクラウドを推奨している
　GCNextの3大メッセージに、ハイブリッド・マルチクラウド・オープン戦略がでていた

境界での問題にマルチクラウドは弱い

・S3からGoogleへデータを送信したときに、gsutilを使っていると中間ファイルが残るなど、スムーズに動作しない部分があった
　AWSへ問い合わせたところGoogleのツールなので、、Googleに問い合わせたところS3のため、、結局コードを追うことに

技術以外のメリットと、ちょっとしたデメリット

・AWSやGCPなど、人脈が広がり、横連携が強くなる
・サンフランシスコ(Google Cloud Next)、ラスベガス(re:Invent)にいける！
・技術的戦略がなく楽しい！BigQueryもRedshiftも利用できる
・両方の新サービスを追えない(勉強コストの増大)
⇒絞って学習している。現状GCPのビックデータ周りは把握しているが、AWSは理解できていない部分がある
・マルチクラウドという観点でのメンバ採用が難しい

マルチ クラウドだけでいいのか？ AI/IoT時代のクラウドのあり方 – 山﨑 亘氏

・ウフル：スワヒリ語で自由を表す

IoTのキーワード – 分散と更新

・例えば来場者の画像を取って、クラウドに送るような場合、次のようなデメリットが発生する
　・レスポンスが悪い
　・通信コストがかかる
　・セキュリティが心配
・上記場合は、データをエッジ側で処理すれば問題は解決する
・しかし運用していくと、次のような要望も出てくる
　・AIモデルの更新が必要
　・センサーデータ取得の間隔や位置も更新が必要
・これらの解決策として、enebularを開発している

ssmjp 2018/08 本当にあった怖い話に参加した。その時のメモ。

ssmjp:インフラ、運用がメインの何でもありの勉強会

Naomiさん

・ユーザ企業にて情シスをしており、以前の会社の話
・ファイルサーバやADなど、「Environment 45℃」で全サーバが停止
・推奨される最高周囲温度35℃
・サーバ増設による冷却装置付きのサーバラックのキャパオーバーが原因かも？
　2011年は輪番停電で扇風機がなかったが、ダイソンだけが在庫があった
・エアコンを数百万かけて設置することにした
　欄間を閉じると消防法のためスプリンクラーと警報機が必要になり高額となった
・しかしエアコンの納期は10月と夏を過ぎていたため、以下対策で乗り越えた　
　・ビル管へ空調24時間稼働依頼
　・空調温度をさげる
　・温度状況を計測して、サーキュレーターで対策
・外部監査はサーバラックに鍵をかけるという決まりがあったが、セキュリティリスクを許容して、事業継続リスクを優先で乗り切った

データセンタ運用であった本当に怖い話 @tcshさん

・予算のない部署のサーバラック
　・42Uフルで抜けない、差せない
　・ただし背面は寝るには最高の気温
　・熟睡していたら、あのラックの背面から足でているけど起こさないでね
　　・知らないうちに自分が設備扱い
・データセンターの電源容量枯渇
　・配電盤が溶融し、5秒後か5時間後にショートする状態に
　・シャットダウン大会
・電話局がリアルダンジョンで死ぬかと思った

皆一度は経験する、あり得ない話 流しのSEさん

・独立した上司に遊びにこないかと誘われ、客先に連れて行かれ、メイン担当者として紹介されたお話

今年最凶の怖いはなし 片山昌樹氏

・ナビプラスはセキュリティ全般をサービスにしている(インシデントレスポンス、フォレンジック、脆弱性対応)
・Huawai怖い
　・利用規約に口座番号や友人情報、リアルタイム位置情報やFacebookアカウントやTwitterアカウント情報などを取得を示唆する文章がある
　・米国政府から名指しで、個人情報を抜くメーカーと言われ、流通禁止の法律が施行されている
　　しかし、日本では大々的に販売されており、モバイルWi-Fiの90%はHuawai(わからないようにしている)
・試しにMateBook Eシリーズを調べてみたところ
　・Webカメラが写真を撮ろうとしている
　・マイクはミュートでも音を拾う
　・query.hicloud.comというHuawaiデータ取得用サイトなどに接続している
・Xiaomiを現在調査中
　・データのPOSTが多い
　・MDMサーバに定期的に通信している

　

運用におけるシェルの役割とそのあり方を考える – 山下和彦 氏

資料：運用におけるシェルの役割とそのあり方を考える

GMOペポバのサービス – ロリポップレンタルサーバ

・秒間2万8千アクセス/秒(DoSを受けた際はこれ以上)
・ビーク8Gbps

Shellに対するいくつかの考察

・Shell = Shell Script (bashで記載されたものを表す)
・RedMonk社(StackOverflow・GitHubでの人気度)によると、言語としては12位くらい

Shellの特徴

・メリット
　・パイプ、オプションを利用した強力な組み合わせ
　・ほとんどの場合は導入コストが低い(インストールの手間なし、依存性なし)
・デメリット
　・テスト実装、変化に強い実装、再利用性の高い実装は苦手

ライフサイクル観点からの考察

・パイプ、オプションが強力すぎて、熟練者でないと見にくいことがある
⇒開発効率化には最適であるが、複数人での運用保守には向いていない(運用の際に負債として残る可能性あり)
・携わるメンバがShellに詳しければ問題ないが、Shellに学習コストをかけるかというと、
　WEBエンジニアは覚えることが多くベターとは言えない

・例外として、USP研究所のようにShellに特化したユニケージ開発手法などが定着している場合もある
　・RDBを利用せず、テキストファイルによってデータを管理

言語特性観点からの考察

・長期的な運用には不向き
・変化が少ない局面については有効
　・バックアップスクリプト
　・監視系スクリプト

なぜ人類はShellをかかなくなったのか？

・Infrastructure as CodeによってLLやGoを書き始めた
・自動化の高度化
　LLやGolangで簡単にプロセスができ、人が介在せずとも処理ができるようになったため
　処理を集めてjob.shとして実行することなどを、自動化と呼ぶ時代ではなくなった

それでもShellが好きな人も

・人は得意な言語で書くため、評価にも反映させる

なぜGolang？

・システムプログラミングに必要なAPIが一通りそろっている
・可搬性が高く、サーバに配置しやすい

まとめ

・長期運用するなら、Shellを頑張るよりも、他の言語で対応したほうが幸せになる

知らなかったこと

・shellcheckというshellの記法をチェックするようなツールもある

サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介 – 船井 覚 氏

資料：サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介

Open-Audit

・コミュニティ版と商用版がある
・20ノードまでは管理可能
・エージェントレス型
・SNMP,WMI,SSHでアクセスして、情報を取得する

できないこと

・収集のみ、設定変更はできない
・時系列での履歴管理
・インデント管理、資産管理
⇒OpenPIEを利用すればできるように

OCS Inventory NG

・エージェント型
・コミュニティ版のみ

ノウハウ丸ごと共有します！ハートビーツの24/365体制を支える人材育成 – 倉持亘 氏

感想

・主体性(自分で考える)を大切にしている
・手を動かさないと身につかない
・障害時に大外ししないことを意識する
に共感した。

24/365を支える体制

・3交代制であり、3チームでローテーションしている
・1チーム5-6人で、役割がある(主担当と副担当、研修生)

目指す人物像

・なぜそうなるかを理解できる。自分で理解して、答えにたどり着ける人材(原則原理)
・技術はツールであり、このツールを利用して顧客へ価値を与えられる
・迅速に復旧までたどり着ける

人材育成におけるテーマ

・主体性
　自分で考えさせる。座学よりも、手を動かして理解してもらう(でなければ身につかない)

研修内容

研修生

・未経験者も雇うため、サーバ構築から障害対応までの基礎を教育する

サーバ構築研修

・目的：LAMP環境の仕組みを理解する
・タワーPCを渡して、あとはよろしく！チェックポイントは提示するが、構築の手順は提示しない
・やっていいこと、悪いことを学ぶ
・たくさん失敗させて、たくさん学んでもらう
・質問に対して、答えを伝えるのではなく、なるべく本人が答えにたどり着くように誘導する
・やったことはBacklogにエビデンスとして残してもらう
　・後で担当者が方向性があっているか確認する
　・ググってコピペしたものではないか確認するようにしている(自分の言葉でかけているか)

ロールプレイング研修

・目的：以下を身につけてもらう
　・技術だけでは顧客に価値を提供できない
　・技術がないと仕事はできない、
・顧客とHBのエンジニアという設定でロールプレイング
　顧客からアバウトな相談事を受けて、必要な情報を聞き取り、顧客の解決策を検討し、プレゼンしてもらう
・チェックポイント
　・Quick & Dirty (完ぺきではないが素早く)を実践できているか
　・顧客を理解できているか(サービスの理解、ビジネスの理解)
　・技術的に正しいことを言っており、もし不明瞭なことがあった場合に持ち帰っているか

障害対応研修＆実践

・障害対応フローを覚える
・調査コマンドを課題ベースで覚えてもらう
　使い方の詳細は説明しない。後ほど理解できているか確認する
・座学で学んだことを実際の障害で対応してもらう

フィードバック

・現場ではうまくいかないことも多いため、フィードバックを実施している
　・その場でのフィードバック
　・Backlogを利用したフィードバック
　　目的：振り返る機会を作る、指導者と研修生の認識をなくす
　　日報のようなものに、わからないことなどを記載してもらい、後日認識合わせをする
　・KPTを使った振り返り
　　・P(自分に足りないところ)：指導者の考えるPと研修生の考えるPのギャップを埋める
　　・T(Pをどうやって身につけるか):なるべく自分で考えさせる
　　・隔週実施

副担当

主担当面談

・主担当とは：シフト内の障害対応の責任者、すべての障害に目を通し、副担当に仕事を割り振る役割
・目的：主担当に必要なスキルを身につける
　・主担当のロールプレイング
　　・災害時のロールプレイング
　　・複数障害が発生した場合のロールプレイング
　　　・面談してフローを作成していくイメージ
　　　・チェックポイントとしては、優先順位をつけて、正しく仕事を割り振れるか、
　　　・論理的に切り分けて大外しせずに復旧までたどり着けるか

育成の課題

・指導者への指導
　人によって教え方が上手、下手がある
・フィードバックする時間の確保
　日頃の業務の中でフィードバックする時間がないときがある

質疑応答

・障害でパニックになる人に対してどうしているか？
⇒自分に自信がないことが原因だと思うため、小さい成功体験を積み重ねるよう教育している

・自分はできている思っている主担当に対してどのようにアプローチしているか？
⇒IT業界は流れが早いため、別途研修を設けている

「使ってみた」では終わらせない！ AWS GuardDutyを使ったサイバー攻撃の検出・分析45分スタートアップ講座 – 鈴木研吾 氏

資料：GuardDutyを使ったサイバー攻撃の検出と分析.pdf

感想 – というよりも知らなかったこと

・ArcSight、SplunkといったSIEMツールがある
・サイバーキルチェーンという標的型攻撃における攻撃手順を標準化したものがある
　これをもとに多段防御を検討することができる

GuardDuty 素晴らしいところ

・GuardDutyは検知だけのため、システム的な影響なし
　内部ではログをコピーして分析するため、遅延が発生することはない
　中の人に聞いた時も、ただただONにするだけでよいとのこと
・金銭面への影響についても、1ヵ月でどれくらいかかるかチェック可能

なぜGuardDuty

・AWSでは想定すべき脅威の種類が増えて、今までの検知ロジックだけでは不足している
　今までの検知が古いというわけではない

オンプレミス時代にはなかった想定すべき脅威の種類

・クラウドサービスとしてのアカウント
・リソースと権限
・動的にスケールするリソース
・Pay as you Goなリソース

GuardDuty in Folio

いくらかかっている？

・11アカウント全てON、$6.38/day
・SOCサービスは月間20万円ほど

誤検知ある？

・とても少ない
・もし誤検知があれば、その条件のアラートを無効にする機能が最近リリースされた

ユースケース？

・GuardDutyは集約する機能しかもたないため、CloudwatchからLambdaに流している
・検知したら、自動的にスナップショットを取得し、別VPCに展開し、フォレンジックするような仕組みを用意することも可能

Interact 2018に参加した。その際のメモ。

Recap: PowerShell Core – 高井 一輝氏

PowerShell Coreとは何か

Windows PowerShellとの違いについて

・Full .NET Frameworkに依存しないPowerShell
・クロスプラットフォーム
　LinuxやMACでも動作する。
・Windows PowerShellと互換性はあるが、基本的には違うもの
・WMFに(建前上は)依存しない
・SSHが使えるバージョンと使えないバージョンがある
・UTF-8(BOMなし)
・Modern Lifecycle Policy(新しいバージョンが出たら、半年の間にアップデートする必要あり)
・WindowsPowerShellと共存可能
・Windows PowerShellは、今後大幅な機能追加やエンハンスは行われない予定

Powershell Coreへ移行すべきか

No。ただし新しくコードをかく場合はPowerShell Coreを意識してもよいかも。

Powershell Coreを使うべき人

・クロスプラットフォームで利用したい人
・コンテナを利用してWindows管理したい人(開発スピードが早いプロダクトを利用している場合)
・PowerShellの動作を変えたい人(オープンソースのため、どうぞ)

注意点

・LinuxからWindowsへのWinRMの通信は失敗する
　最新のWindowsは認証されていないと受け付けないようになっており、PowerShellCoreでの認証周りの設定が難しい、らしい。

Windows Admin Center -Project Honolulu改め- – 指崎 則夫氏

※Inside Previewを利用しているため、変わってくる可能性も

Windows Admin Centerとは

・ブラウザを利用して、サーバを中央管理することが可能
・EdgeもしくはFirefox(ただし検証はされていない)が無難
・Chromeは画面遷移で認証エラーが多発する
・インストールが簡単(ただし証明書が絡むと少し手間がかかる)
・インストールファイルサイズが数10MBと軽量
・10GB以上のCSVがあれば冗長化構成をとることができる(2ノード以上のWindows Server 2016 failover Cluster)
・イベントログの確認、サービスの起動、ファイルの確認、レジストリの操作など管理できる

Admin Centerからサーバへのアクセス方法

・PowerShell or WinRMで接続するため、各サーバに許可設定をする必要がある

管理される側要件(古いOSについて)

・WinSV2012(WMF5.1以上)
・Win2008R2(WMF5.1以上)も最新のAdminCenterは管理できる
・ワークグループなWindowsはレジストリを登録することが必要

Microsoft Azure Global VNet Peering(仮) – 廣瀬一海氏

・VNet Peeringを利用すると、AzureがSDN(LVGREやSmartNIC(FPGA)を利用)であることを感じられる
・FPGAを利用してパケットチェックして機械学習を利用して、DDoS攻撃を処理している
・Azureは実質WANのようなもの。リージョン間のネットワークもMicrosoftで海底ケーブルを引き、すべて自社網を利用する唯一のパブリッククラウド
・東京リージョンから大阪リージョンへは2msレベル
・Azureは33000マイルの自社網を持ち、世界二位のグローバルネットワークを保有している(1位はペンタゴン)
・ExpressRouteは南極以外からは接続できる
・VNet PeeringはvNETのエンドポイントのBGPルーターを利用して実現している
　制限として10地点としか接続できない
・NW設計について、サブネット分離(Publicサブネット、Privateサブネット)という鉄板も世界をまたいだ設計を考えると、破綻する
　事業ネットワーク、論理ネットワークを考慮して、事業の展開に役立つような設計が大切

Interact 2018に参加した。その際のメモ。

Azureの契約直前・直後に意識しておくこと10箇条 – 足利 惟 氏

Azureそのものの管理の話。

自己紹介

・株式会社pnop所属。
・JAZUG運営メンバー。

Azureの契約プランを一度確認するべし

・サブスクリプションにはさまざまな契約プランがある。
・Visual Studio サブスクリプション(旧MSDNサブスクリプション)には月1万7000円利用できる特典がついている。

従量課金制

・使った分だけお支払い。基本はクレジットカードを利用し、Microsoftへ直接支払い。
・デメリット
　・会社のクレジットカードを作成する必要がある。(意外と敷居が高い)
　・請求書払いの場合、SendGridなどサードパーティと外部サービスは購入も支払いもできない。

Azure CSP(Cloud Solution Provider)

・Microsoftがオススメしている。
・サブスクリプション + パートナーが提供する付加価値。
・購入方法はパートナーの仕様に依存し、パートナー経由で購入する。法人のみ。
・デメリット
　・ASM(旧型式)のリソースは作成できない。移行の際にボトルネックになる可能性がある。
　・Azure Marketplaceの従量課金製品のほとんどは購入できない。(BarracudaのFW製品など)
　・Microsoftのサポートは購入できない。(パートナー提供のみ)

EA(Enterprise Agreement)

・大企業向けの一括購入プラン。基本的に1社1アカウント。
・年間160万円以上(？)利用する場合に利用可能。
・LPA(ライセンスプロバイダー)経由で購入。
・デメリット
　・年間使用分を事前に購入するため、年間金額を予測して購入しないといけない。
　　(余ったものは返ってこない。これはクラウド？)
　・Azure Marketplaceの購入はできるがほとんどの場合は別請求となる。
　　(足利さんはオラクルの製品を利用していて、別請求で100万円ほどかかったことがある。)
　・StorSimpleを利用したいのであれば現状EA一択。

MSA(MicroSoftAccount)と組織アカウントの違いを理解すべし

・MSA：個人で作成できるアカウントで、Microsoftが管理する。
・組織アカウント：企業が組織レベルで作成するアカウント。Azure ADに情報が格納される。
・MSAにリスクがあるため、Azureのアカウントは、すべて組織アカウントで管理することがオススメ。
・MSAのリスク
　・セキュリティポリシーが強制できない。
　　パスワードポリシー、多要素認証、監査など。
　・5年ログインしないとアカウントが無効になる。
　　Azureサブスクリプションの管理者の場合は、サブスクリプションが無効になる可能性がある。

Azure ADは最初に作っておくべし

・MSAを起点としてサブスクリプションを作成すると、メールアドレスに応じたAzure ADテナントが勝手に作成される。
・CSPはこのリスクはない。
・EAの場合は注意が必要。以下URLから先にAzure ADを用意可能。
　https://account.azure.com/organization/

Azure ADの管理者を理解するべし

・Azure ADの管理者はあくまでAzure AD内部を管理する。
　そのためユーザを作成しても、そのユーザはリソースにアクセスできない。
　(サブスクリプションの入力を求められる。もしくはサブスクリプション内で適切なロールを割り当てる必要がある。)

AzureADとサブスクリプションの関係を理解するべし

・Azure AD テナントに複数サブスクリプションを紐づけることが可能。
・Azure AD テナント間でサブスクリプションを譲渡可能。
・MSAはAzure ADではゲストユーザーとなる。
・ディレクトリを一緒にしておくとVNET Peeringを使うことが可能になる。

むやみに管理者ロールを渡すべからず

・RBAC(Role-Based Access Control)を利用して細かくリソース管理すること。
・管理者ロールはサブスクリプションを削除もできるし、所有者を無尽蔵に増やしていくことも可能。
・作業時のリスクを減らすために、適切な役割を割り振るべし。

リソース管理の便利機能を抑える

・リソースロック
　すべてのユーザに削除禁止、読み取り専用どちらかの状態にリソースをロックする機能。
・Azure Resource Policy
　リソースに関する規則を決める。RBACと違いデプロイ中のリソースプロパティに焦点。
　Dシリーズしか作成できない、東京リージョンにしか作成できないなどの制限を付与できる。
・Management Group(Preview)
　複数のサブスクリプションを管理するためのグループ。

サポートは必ず契約するべし

・Standardが値下げされてきている
・テクニカルサポートは有償サポート契約が必要
・パートナーになっている場合は、プログラム特典のサポートが利用できるかも
　(Microsoft Partner Network・MSDN・Signature Cloud Support)

感想、というよりも疑問

・AzureはAzure ADを1つ作成して、そこにユーザを作り、AD周りの権限を与える。
　サブスクリプションをAzure ADに複数割り当てて、ユーザにサブスクリプションごとにリソース権限を与える。
　という使い方であっているのかどうか？
・アカウント管理者(サブスクリプション管理者)とサービス管理者はわけたほうがよいのか？

参考 – わからなくて調べたこと

Azure サブスクリプションから CSP への移行【10/16更新】
Azure の購入方法