Microsoftが主催する年に1度のカンファレンス、de:code 2018 に行ってきました。

このイベントは、AzureやMicrosoft 365などのMicrosoftの最新の製品やとりくみを、Microsoftの社員やそれを使っている企業が発表、ディスカッションするイベントです。

この記事では、そんなイベントで僕が聞いた内容や考えたことをまとめてみたいと思います。

今回は2日目の参加報告です。1日目は昨日の記事をご覧ください。

Microsoft de:code 2018参加報告（1日目）

参加したセッション

2日目に参加したセッションは以下の通りです。

• [CI09] クラウド アーキテクトへの道 ～ 基礎から学ぶサービス利用設計 (9:30〜10:20)
• [AD30] なぜ、そのサービスを選ぶのか？ークラウドにおけるアーキテクチャ選択眼 (11:00〜11:50)
• [CI29] 結局、Azure を活用したIoT ってどんなことが出来るの？どうつなぐの？の答え。 (12:20〜13:00)
• [CI10] 今更見られない “コンテナー” のキホン (13:30〜14:20)

本日はシステムのアーキテクチャについて考えるセッションが多めになっています。「Azureにいろんな製品があるのはわかった。使い方もなんとなく把握した。でもどうやって実戦投入すればいいの？」というのが1人でAzureを触っている上での悩みだったため、この機会にまとめていろいろなアイデアや事例を聞いてしまおう、という目的です。

また、本日は夕方に別の予定が入っていたため、15:00以降のセッションは参加できずでした。ここまで1つ1つのセッションがとても勉強になっていたため、3コマも逃してしまったのはとても勿体無い感じがしますが、そこは後からアップされた資料や動画で補完していきたいと思います。

本日のセッションでは、一貫して「最適な選択肢は自分で考える」というメッセージを感じることができましたので、1つ1つのセッションについて振り返る前に、まずはそのことについて書いてみたいと思います。

最適な選択肢は自分で考える

Azureの7つのアーキテクチャスタイルを適用すればどんなシステムでも正解になる訳ではありません。Azureやその他のクラウドを利用することが、常にオンプレよりも優れているわけではありません。AIやIoTを使ったからと言って、それは紙媒体などのローテクな情報伝達の手段を使ってはいけないわけではありません。

これらの新しくて流行りでイケてる手法は、あくまで選択肢のひとつであり、既存の技術や考え方にとって変わるものではない、ということが、今日参加したセッションを通して感じたことでした。

AD30で鈴木雄介さんは、流行りだから、趣味だから、好きだからという理由でアーキテクチャを決めるのではなく、「なぜそのアーキテクチャ設計にしたのか」を自分で説明することがエンジニアにとって大切だとおっしゃっていました。

これはアーキテクチャの設計に限った話ではないと考えています。

UI/UX、システム構成、開発環境、さらには社内政治など、システムに要求されること、考えなければならないことは案件によって様々です。そのように様々な課題を解決するために使われる技術にはそれぞれメリットとデメリットがあり、使いどころが必ずあります。新しい技術だから、流行りの技術だから必ず解決するというものではありません。

ビジネスで高い価値を発揮するエンジニアになるためには、まずそのことを理解し、そして新旧それぞれの技術や考え方に触れて引き出しを増やし、それを組み合わせてプロジェクトひとつひとつの状況に合わせて最適な回答が自分で考えられるようになることが大事なのだと理解しました。

その引き出しを増やすために、エンジニアは自分でAzureの製品も触ってみるし、de:codeのようなイベントに参加して色々な事例や考え方を聞いてみるし、Qiitaなどでインターネットにアウトプットしてみるのだと思います。「すごい人」が言っていたことを正解として、そのまま自分の現場に当てはめるというワケでは決してない、ということだと思います。

では、ここまでざっくりとまとめた上で、各セッションの振り返りをしてみます。

[CI09] クラウド アーキテクトへの道 ～ 基礎から学ぶサービス利用設計

クラウドを利用したいという企業が陥りやすい失敗に、「クラウドが全てを解決してくれる」という幻想があります。今までオンプレで頑張ってきて、運用面で様々な問題が出てきたけれど、クラウドに以降すればまるっと解決する、という過度な期待です。

また、クラウドへの移行には大きなコストがかかります。それは教育コストであったり、（エンドユーザーからの見た目は変化しない）移行のための工数であったり、移行によって発生しうる障害などのリスクです。

そのため、クラウドへの移行の精度をあげるためにも、クラウドを活用したシステムがどういうものなのかを理解し、実験し、議論し、改善する、というサイクルが欠かせません。その上で、システムをどうクラウドに対応させるかの判断が求められます。

アーキテクチャスタイル

しかしながら、ただ「考えてみよう」と言っても、クラウドの活用方法について0から議論、試行錯誤していたのでは時間がいくらあっても足りません。そこでMicrosoftは、「アーキテクチャ スタイル」という形でよくあるパターンをドキュメントにまとめています。

アーキテクチャ スタイル | Microsoft Azure

ここで気をつけたいのが、「このアーキテクチャスタイルが正解だ！」と誤解してしまうことです。

アーキテクチャスタイルなどはあくまでクラウドをうまく利用するための「選択肢のひとつ」であり、大事なのは実現したいシステムの要件に合わせてエンジニアがこれを参考にしながら考える、ということです。

また忘れてはいけないのが、「全てをクラウドで解決する必要はない」ということです。問題解決において最適だと思えばクラウドとオンプレを組み合わせたアーキテクチャにする場合もあるし、一気に全てをリプレイスするのではなく、順番にクラウドに寄せていくという手法もある。そのために移行中のアーキテクチャを考える必要がある、といったことが議論されていました。

[AD30] なぜ、そのサービスを選ぶのか？ークラウドにおけるアーキテクチャ選択眼

このセッションでは、オンプレと比べてクラウドを利用したアーキテクチャ設計がどのように変わったのかについて話されました。

クラウドにもIaaS、PaaS、SaaSなどいろいろあり、その分類によってIaaSはコンテナより上の層すべてを、PaaSは（製品によるものの）ミドルウェアより上の層を、SaaSは設定とデータさえあればすぐにシステムを構築できるところが魅力ですが、いずれのサービスもオンプレでは自分たちで試行錯誤と作業をしなければならなかったようなサーバーのスペックや台数調整、DBの細かいバックアップやクラスタ構成などの設定などはコンソールの案内に従って選択していくだけなので、柔軟に変更ができることが強みです。

そんなクラウドサービスですが、これを適用したアーキテクチャを考えるにあたって気を付けたい点が2点あります。

オンプレの設計をクラウドに適用するのではない

オンプレにはオンプレの、クラウドにはクラウドの特性があり、どちらを使うかによって最適な構成は異なります。

例えばクラウドはコンテナ技術と組み合わせることで、バッチ処理のような特定のタイミングだけ実行するプログラムに対しては実行するときだけ環境を作る、という選択をとることができます。バッチ処理のために1台追加でサーバーを用意する必要も、アプリケーションが動いているサーバーを間借りする必要もありません。

アプリケーションのバージョンアップについても、すでに動いているサーバーを止めてバージョンアップしてつなぎ直して、ではなく一時的にバージョンアップ前のサーバーと同じ数だけ「バージョンアップ後のサーバー」を増やし、ロードバランサでバージョンアップ後のコンテナにリクエストを振り分けるよう設定し直すことでユーザーから見たバージョンアップを完了できます。つまり、リリース作業の手順や時間が変わる、ということです。

このように、クラウドにやクラウドに最適化されたやり方があるため、オンプレとは違う考え方でアーキテクチャを考える必要がります。

クラウドが常に正しい選択肢ではない

これは先ほど書いた通り今回一番頭に残った内容ですが、そのような便利なクラウドでも、常にそれを選択することが正しいわけではない、ということがセッションで議論されました。

クラウドは便利ですが、クラウドを利用するということは、それはつまり自分たちのサービスでできることがそのクラウドサービスが提供する範囲に限定される、ということも同時に意味しています。

世の中にはさまざまな会社があり、そこで生まれる要件は千差万別です。クラウド技術はそれらすべての要件にこたえられる銀の弾丸のようなものではなく、あくまで選択肢のひとつにすぎません。

エンジニアとして大事なのは、新しいサービス、新しい技術に飛びついて無条件にその利用を前提としたアーキテクチャを考えるのではなく、新旧ひとつひとつの技術でどこまでのことができるのか、それを利用することでビジネスがどのように変化するのかを理解した上で、最適と思われるアーキテクチャを自分で考え自分で説明できるようになることです。

新しい技術が出てくると、大半のエンジニアは「ちゃんと流れに追いついて環境を変えてかなきゃ！」と考えることが多いと思います。「流れに追いつく」のは大事ですが、「環境を変える」のが技術の特性と状況次第では必ずしも最適とは限らないことに注意する必要がありそうです。

個人的な感想ですが、スピーカーの鈴木雄介さんは次から次へと出てきては変化する技術をとても冷静に見ていて、とてもカッコ良い方だと思いました！

[CI29] 結局、Azure を活用したIoT ってどんなことが出来るの？どうつなぐの？の答え。

こちらはランチセッションということで、AzureサービスとIoTデバイスを組み合わせたアジュールパワー株式会社の取り組みの紹介でした。

その中のひとつに「子供だけの旅を家で見守るトラッキングデバイス」の紹介があったのですが、そこで話されたことがこのセッションの中で個人的に勉強になりました。

「子供の旅をトラッキングするデバイス」と聞いてまず思い浮かべるのは、一定時間ごとに位置情報をクラウドに発信するデバイスです。たしかにそれはその通りなのですが、ここで議論された内容は「それだけでは不十分」というものでした。

子供を見守りたい親というのは、ただ位置情報さえ分かれば安心するわけではありません。

例えば防波堤で子供が釣りを始めた場合、トラッキング情報として見られるのは「防波堤で子供の動きが止まった」という状況だけです。これだけを見ると、「もしかしたら子供が足を踏み外して海に落ちてしまった」という不安を親は受けてしまいます。実際には釣りをしているだけだったとしても親にはそれが分かりません。

また位置情報上は電車に乗って移動しているように見えても、その電車が正しいのか、その電車にその時間に乗った先に泊まれる場所があるのかどうか、それも分かりません。

そのような不安の解消に役立ったのが、あらかじめ作成した「手書きの予定表」と「携帯電話」だったということです。

ユーザーが求めているのはあくまで「安心感」であり、その課題を解決するために必要なのは必ずしも優れたIoT製品や技術だけではなく、「手書きの予定表」のようなアナログな手段が「安心感」に大きく貢献したことを考えると、ここでも「新しい技術」だけが常に最適な解ではないことがうかがえます。

AIにしろIoTにしろクラウドにしろ、サービス開発をする際はそのユーザーが何を本当に必要としているのかを明らかにした上で、それを満たす手段をデジタル・アナログ、技術の新旧問わずに検討する能力が大切であることが伝わりました。

[CI10] 今更見られない “コンテナー” のキホン

このセッションは、本当に「コンテナ」技術をほとんど触ったことがない人のためのコンテナ入門で、デモが中心のセッションでした。

Nginxが入ったイメージを $docker run してブラウザでデフォルト画面を開くだけのデモから始まって、 $docker build コマンドで自分でコーディングした index.html をコンテナに詰め込むデモ、コンパイルようと実行用のコンテナを別に立ててみるデモなど、（CLI環境が好きな僕にとっては）とても分かりやすくて楽しいデモばかりで、今までどうも触ってみる気にならなかったDockerの利用イメージを少しつけることができました。

だいたいの概要は知っている程度の技術についてもう一歩学んでみようと思ったとき、デモを見るというのがとても効果的なのだということを身をもって体感することができました。

もう一つ印象的だったのは、スピーカーの吉田雄哉さん（通称「パクえ」さん）が、「Kubernetesは始めは使わない方が良い」とおっしゃっていたことです。

そのココロは、Kubernetesは大規模なシステムにコンテナ技術を導入する場合において、コンテナの設定と起動自体に手間がかかってしまう問題を自動化によって解決するために登場したもので、小規模なシステムでちょっと使ってみよう、という用途としては複雑すぎるから、というものでした。

Kubernetes自体もまだまだ変化し続ける技術で、それに追いつくのにも学習コストがかかるため、まずはAzureのコンテナ系のサービスを使い倒したあとに必要になったら調べはじめる、というくらいの考え方で良いのではないか、ということでした。

ここでも、流行りの技術が常に最適な選択肢ではない、というメッセージを感じることができました。

２日間のまとめ

最初に書いた通り、今回のde:codeへの参加を通して、なぜエンジニアにとって新しい情報をインプットすることや新しい技術に触れてみることが大事なのかを整理して理解することができました。

このような大きいイベントには必ず「すごい人」が出てきますが、彼ら、彼女らは必ずしも「全ての問題を解決できる神様のような人」ではありません。新しい技術や考え方を一足先に議論して発信できる立場にいる人だったり、今まで培ってきたノウハウが頭で整理されていて人に伝えることができる人たちなのだと思います。

そして新しいプロジェクトに取り組む場合、要件を整理して理解して、出てきた課題を解決するために最適と思われる回答を考えていく、という点は「すごい人」も自分たちもスタートラインは同じです。

新しい技術や製品が出てきて、でも従来の手法が使えなくなるワケではない、という状況は最適な回答を考える上で知らなければならないことが増えることになり大変だとも言えますが、逆にそれらをひとつひとつ把握していけば、最適な回答にたどり着くための選択肢がどんどん増えてよりどりみどり！と考えることもできると思います。

いろいろ聞きながら考えながらツイートしながらあっという間に終わった2日間ですが、参加報告にまとめたようなことを思い出しながら、まずは僕も今回知ったMicrosoft製品や技術に触れてみるところからやってみようと思います。偉そうなことをいろいろブログに書いたところで、Azureも機械学習もコンテナもまだまだレベル100の状態なのは変わらないので。

最後に、今回のイベントの招待枠をくださったMicrosoftのみなさま、ありがとうございました。de:codeは自分にとってとてもプラスになったイベントでした！