【Microsoft de:code 2019】de:code 2019に参加してきました！

こんにちは。

先日、ビヨンドがMicrosoft様に招待していただき、de:code 2019に参加してきました！
僕が参加したセッションの感想や、de:code 2019のパーティの様子などをお送りしたいと思います。
今回、私がインフラエンジニアなので、開発者向けよりもインフラ向けのセッションをメインに見てきました。

基調講演

以下の方々のお話を聞きました。
平野 拓也様 (日本マイクロソフト株式会社)
ジャレッド スパタロウ様 (マイクロソフト コーポレーション
ジュリア ホワイト様 (マイクロソフト コーポレーション)
アレックス キップマン様 (マイクロソフト コーポレーション)
基調講演は以下のリンクからYoutubeで確認できます。
https://youtu.be/GtVcDo1G8r8

平野様はAIの話をメインに、阿修羅像の年齢を測定する装置や、火事になってしまったノートルダム大聖堂を修復するために3Dの視覚モデルを作成するプロジェクトを進められているとのことでした。
他にもオープンソース路線の拡大ということで、RedHatOpenShiftやVMwareとの連携、共同開発を進められているそうです。

ジャレッド スパタロウ様からは、WindowsTerminalの話がありました。
WindowsTerminalを使ってみて、Linux,Windowsともに接続を試してみたいと思います。

ジュリア ホワイト様からは,Azureの最新サービスや動向について詳しく説明がありました。
特に、AzureDevOpsの話ではAzureKubernetesをメインに本当にワクワクとする口調で話していらっしゃいました。
アレックスさんがHoloLens2のデモをしており、アレックスさんの横にいるVirtualなアレックスさんがとてもリアルに感じました。
僕も今度行くことがあれば、HoloLens2を体験してみたいです！

参加セッション

しくみがわかる Azure Kubernetes Service (AKS) ～開発者目線で Kubernetes の基本を理解する～

正直kubernetesって結局何なの？という状態の僕でも、このセッションを聞いてkubernetesが何なのか
どういったことができるのかをデモを交えながら説明していただき、理解が深まりました。
説明もとてもわかりやすく、設定すべきポイントなども交えてもらったのでもう一度資料を見直したいと思います・・！
最後におっしゃっていたのですが、kubernetesを利用するには、まず仕組みをしっかりと理解することが一番大切だと・・おっしゃる通りだなと思いました。

HashiCorp Terraform Azure Provider チュートリアル

20分間という短いセッションの中、Terraformの説明から、メリット、どれだけ便利なのかなどをお話ししていただきました。
弊社寺岡がTerraformが好きで、以前に社内勉強会で教えてもらったことの復習になりました。
最初にHCLで設定ファイルを作るのは面倒だと感じていらっしゃったそうですが、今ではTerraformなしで構築する方が億劫だと仰っていました。

マネージド Kubernetes ガチ本番運用 in ZOZOTOWN

あのZOZOTOWNです。
個人的にいつもお世話になっております。

ZOZOTOWNはオンプレサーバーが多いらしく、サービスの成長に伴い増加していくサーバー台数や
セール時に耐えられる台数を常に用意していることで運用負荷が高くなっていることが課題にあったようです。

なぜ、kubernetesを採用したのかという話では
①柔軟な台数増減
ZOZOTOWNでは定期的なセールを行うので、柔軟にスケールできることが必要
②アプリケーションを動作させるまでの設定が面倒なのでコンテナ化したい
③オートスケールできる
kubernetes採用の目的は、システムの安定運用、運用負荷の軽減、マイクロサービス化に伴うマルチクラウド化を視野に入れた設計でZOZOTOWNの可用性を上げるためとのことです。

なんとシステムリプレースは2017年の8月からメンバー5人で行っているそうです・・・現在もメンバー募集していました。

kubernetesの運用については、確かに運用が楽になる部分はたくさんあるが、覚えるべき知識が幅広く低レイヤーから高レイヤーまでたくさんあるとのことでした。

何故マイクロソフトのAzureを選んだかという話では、マイクロソフトユニファイドサポートが手厚いのが大きなポイントだったようです。
何度でも問い合わせができて、マイクロソフトの技術者と問題解決ができる、オンプレの問題も相談できることが魅力だったようです。
確かにサポートに問い合わせをして、すぐ返事をもらえるなら、自分で調べるよりも早いし正確な可能性が高いのは大きな魅力ですね。

DevSecOps 時代のログ マネジメントとセキュリティ

DevOps視点のログマネジメントについてのお話でした。
DevOpsでは開発ログ、運用ログ、監査ログの3つのログを管理する必要があります。
私自身はDevOpsを経験したことがないのですが、MSPにおいてもログの管理って非常に重要になってきますよね。
そもそもログを取ってなかったら、障害対応とか障害が起きていた瞬間の情報をその瞬間だけしか確認することができないですからね。

開発ログ、運用ログ、監査ログそれぞれ3つのログのポイントを教えていただきました。

開発ログ
・開発者が行う作業に合わせてどのようなログが欲しいのか決める
・自動化されたテスト環境では、開発ログは開発環境に含まれるため設計の必要はない場合もある
・開発ログの保存期間は長期的でなくてもよいが、作業者の働き方の分析のために開発ログは一定期間保管しておいてもよい
⇒開発が終了した後も、開発の効率化に向けた学習と成長のために作業記録を保管しておいたほうが良い

運用ログ
・運用者自らが判断し、作業ができるような「ダッシュボード」と「セルフサービスインターフェース」を設計する
・運用者の作業も作業ログとして残す必要がある
・運用上の作業においては「変更管理」プロセスにのっとって行うため、作業をロールバックできるように設計を行う
⇒ダッシュボードがあると非常に助かります。
ぱっと見ただけでこれが原因だなって検討がつくことがあり、実際に原因とマッチすることがあります。
⇒作業ログを残すことも大事だと思います。
その作業の影響で何か障害が発生した場合に、切り戻しに時間がかかる、または戻せないということが発生する可能性があります。
事前に作業内容を手順として残しておくのが一番良いのではないかと思います。

監査ログ
・監査人が判断できるような報告書を作成できるように、ログの明細を作る
・セキュリティ監査においては「暗号化している」というだけではなく、権限者が適切にデータを扱っていることなども説明できなくてはならない
・リモートジャーナリングなどを活用して、ログの客観性を証明する

実践 NoOps ～NoOps で本当に働き方は変わるのか?～

NoOps(No Uncomfortable Ops)（運用保守の”嬉しくない”をなくそう）の視点で実際に大手企業様が実践してみたお話を聞けました。

システム運用保守での「嬉しくないもの」
1.ユーザーの体験を妨げないシステム運用保守の実現
（障害時のダウン、計画停止、負荷集中時の性能低下、etc）
2.システム運用保守で発生する「トイル」の最小化
（リリース手続き、パッチの適用、リソース監視、待機、etc）
3.システム運用保守コストの最適化
（余剰資源を持たない、適正品質、時間外勤務、人材活用、etc）

toilとは「労苦」の意味のようです。
手作業、繰り返される、自動化できる、戦術的、長期的な価値を持たない、サービスの成長に対してO（n）である
ものはtoilと呼ぶようです。

システムは利用者への「価値」と提供者の「負担」でできているとお話ししていただきました。
確かに・・運用する側として
理想は「価値」を大きく、「負担」を小さくしたいですね。
でも現実は「価値」が小さく、「負担」が大きいことばかり。

そこでNoOps、運用の”嬉しくない”「負担」を減らそうという話です。
弊社でも僕が、無駄を減らして業務を効率化させようと取り組んでいるチームに所属しているのでタイトルの時点で興味深かったです。

NoOpsには「守り」と「攻め」があるようです。
「守り」のNoOpsの特徴
・監視通知の自動化
・リトライの自動化
・構成変更の自動化
・方式の標準化
・状態の可視化
（そのほかSRE活動など）

「攻め」のNoOpsの特徴
・Container
・Microservices
・Serverless
構造的にOps不要なシステムとして設計しましょうという話です。

次に実際にNoOpsに取り組んでいる企業様のお話です。
富士フィルムソフトウェア株式会社様
「写真・デザインの管理・共有クラウドサービスIMAGE WORKS」のシステムでNoOpsに取り組んでいらっしゃいます。
エンジニア目線とマネージャー目線で語っていただきました。

エンジニア目線

■NoOps前
・リリース作業の負荷を下げたい
システムを止められるのは深夜だけ、サーバーが増えるとリリース作業も多くなる
誰かの大量操作はサービス全体に対してリスクとなる、誰がなにしたかの調査も復旧も大変

■NoOpsで何をしたいか
・リリース作業の負荷を下げたい
AppService,AzureFunctionを利用（ここでAzureの登場です）
AzureDevOpsを利用してビルド・デプロイを自動化

・障害時の対応工数を抑えたい
・１つのAppServiceに機能を集めず、処理ごとにサービスを分解する
・別のリージョンにもスタンバイ機を置き、いつでも切り替えられるように

■NoOpsで良かったこと
・リリース作業の負荷を下げたい
サービス停止無しでいつでもリリース可能
ボタン一つで本番環境にリリース

・障害時の対応工数を抑えたい
想定外のエラーが出てもサービス全体が止まったりしない
別リージョンのスタンバイ機が動作するので復旧対応も余裕ができる

■NoOpsで悪かったこと
・リリース作業の負荷を下げたい
10%位の確率で失敗するため確認が必要
失敗してもステータスは正常となるため目視確認が必須

・障害時の対応工数を抑えたい
処理を分ければ分ける子ほど、監視や確認項目が増える
開発者運用者は分けた分だけ処理フローを理解しなければならない

いつでもリリースできるようになってとっても便利になった反面
いいことばかりではないということですね。
確かに確認する項目が増えると、それだけ時間を取られることになります。

マネージャー目線

NoOpsの成果を焦らない

最初はコストがかかる場所が移動するだけとおっしゃっていました。
具体的には
NoOps取組前が
事業系コスト(60%)、保守系コスト(30%)、改善系コスト(10%)
NoOps取組初期
事業系コスト(60%)、保守系コスト(20%)、改善系コスト(20%)
といった具合です。
NoOpsで目指すべき姿は
事業系コスト(70%)、保守系コスト(10%)、改善系コスト(20%)
保守系コストを減らして事業系コストに回すということですね。

以下のように全体のコスト自体が小さくなるようには、うまくいかないとのことでした。
事業系コスト(40%)、保守系コスト(10%)、改善系コスト(10%)

SREチームの編成について

・やっぱり理想通りにはいかないもの
必要なスキルやマインドが従来の開発/運用とは違う
開発～サポートまで全部やるとか無理
プログラムとか書けないし（Opsメンバーの意見）
機能開発がやっぱり花形だし（Devメンバーの意見）
これはよく聞きますね、SRE本の通りを目指すのは難しいという話です

・コンバートするか新規育成か？
サッカーの世界のトップチームとJリーグを引き合いに、トップリーグの戦術だけ真似しても選手の能力が伴わないとだめだという話をされていました。
なるほど・・・とても分かりやすい例えです。

チーム編成については現在も模索中のようです。

アサヒプロマネジメント株式会社様
伊藤忠テクノソリューションズ株式会社様
やったこと
・オンプレからフルマネージド
・自動復旧可能なアーキテクチャ
・自律的な運用

フルマネージドのアーキテクチャでも運用課題が存在するようです。
運用現場から
「お客様の業務はどんどん自動化されているのに、自分たちの業務が自動化されない・・・」
⇒【挑戦】RPAに任せてみる
⇒【結果】定例業務の自動化に成功
⇒【課題】ロボット実行環境の保守が発生、処理遅延がしばしば発生する
RPAについてほとんど知らなったのですが、定例業務（Excelの作業等）等で大活躍しているようですね。
NoOpsはインフラ構成をどうこうするだけじゃないということですね。

「システムの利用状況に合わせてリソース調整を行う」
⇒【挑戦】スケーラブルアーキテクチャの実現
⇒【結果】利用ピーク時の作業軽減
⇒【課題】稼働中システムへの適用ができていない
スケーラブルアーキテクチャはNoOpsでは当たり前という印象を受けました。

まとめ

記事が結構長くなってしまいました。
それだけ中身の濃いイベントでした。
他にも以下のセッションに参加したのですが、どれも面白かったですし、知らないことだらけでした。
「そのオンプレの DB、どうやって Azure SQL Database へ移行しますか? ～Benesse 進研ゼミの事例～」
「人生 100 年時代の PDCA 〜キャリア、働き方改革に活かせる古くて新しい PDCA の回し方〜」
「AWS 技術者向け Azure サーバーレス」

1日目の最後には豪華なパーティが行われました！
たくさんの料理やスイーツを食べながらワイワイとパーティの雰囲気を楽しみました。
DJが本格的といいますか、本当にクラブミュージックでここはクラブかと思いました。

ちなみに、あの「本田圭佑」もゲストとして来ていました。
Twitterをもともとフォローしてたんですが、本物が見れてちょっと感動しました。
「じゅんいち・ダビットソン」ではなかったです。本物です。

参加してよかったセッションしかなかったです。
来年も是非、弊社の後輩たちにも行ってみてほしいなと思います。