JANOG45 Meeting in Sapporo に参加してきた（後編）
JANOG45についての過去の記事
前編と中編は以下。今回がJANOG45については最終回。
JANOGアップデート
・JANOG45の参加者数
今回のJANOG本会議の参加登録数は1301名、懇親会の参加者が778名だった、とのこと。当日参加の人を加えると、もっと多くなる見込み。地方開催を続けているが、参加者数は増加傾向にある。地元の北海道からは111人の参加とたくさん来てもらえた。東京・神奈川・千葉・埼玉はいつも通り多い。初参加の人の割合は30％。年齢層は40代が多いが、20代も以前より増えてきた。
・若者支援プログラム
今回、若者支援プログラムから12人の参加があった。JANOG35より「未来のインターネットをつくる人」を支援するためのプログラム（意欲があっても経済的に参加が難しい若者に旅費交通費等の支援）を行ってきた。
任意団体での支援継続が困難となり、昨年9月より法人化。一般社団法人IPネクスト育成協会を設立した。「JANOG若者支援プログラム」を実施している。
・Upcoming JANOG Meetings
今後の予定は下記の通り。47か48のどちらかには参加する予定。
Janog46 沖縄 2020/7/8-7/10
Janog47 福岡 2021/1/27-1/29
Janog48 岐阜 2021/7月
・平井さん会長退任
新たな挑戦に向かうため会長を退任されると発表があった。後任の会長はJANOG46までに選任される予定とのこと。
都庁をバックにした動画メッセージがあったが、会場からは温かい拍手が送られた。笑いもあり、場がほっこりとした瞬間。長い期間大変お疲れ様でした！
急成長を支えるFastlyスケーラブル・グローバルネットワーク
FastlyはCDNを売っている会社。24時間を地域ごとでローテーションをまわしている、という話がとても興味深かった。
「Follow th Sun shifts」と呼ぶらしい。例えば以下のようになる。
APAC 0:00-6:00 UTC（10:00-16:00 JST）
EMEA 06:00-12:00 UTC ※ Europe, the Middle East and Africa
US East 12:00-18:00 UTC
US West 18:00-24:00 UTC
これを15人の人数で運用している。Fastlyが少人数の運用チームで、どのように大規模グローバルネットワークを運用しているのか。
・「No Backbone」「No Router」「No Loadbalancer」で設計されている。
・ 運用はすごくシンプル。
1コマンドで出来るようにしている。ツールをつくって1コマンドでオペレーションをしている。
まとめると、ネットワークデザインと、ネットワーク運用の2つによって、少人数で大規模グローバルネットワークの運用を実現している。
常識が変わる責任共有のカタチ
これも楽しみにしていたセッションの1つ。
◆ 中里さん（GMOインターネット株式会社）
とある外資クラウドの人たちと飲んでいた時、データセンタがまるっと落ちた時の話をしていた。どうやって謝ったのかな？と思った。
謝るとは、合意形成に置き換えられるのでは。
身近な例としては「何でこんなバグあるの」「ちゃんと保守交換してよ」「何で回線切れるの」「対応納期守ってね」などがある。ベンダを激詰めしている先輩もいた。これって双方とも辛い状況。
サービスを提供する側、受ける側の事情には「責任取りたくないし、リスク利便性よりもリスクを回避したい」「得にならないことはしない」がある。
でも、「おっかない上司に言われればやる」「評価・昇給などに繋がることはやる」でもある。
これを踏まえて、合意形成するための材料を集める必要がある。期待値の不整合・リスクなどをきちんと説明しない傾向がある。これって合意形成できている？
不確実性要素・様々な不確実性要素がある品質の責任を1つのサービスでとるのは難しい。運用でカバーすると人に負荷がかかる。
対話、事前共有、意向確認などを行い共通認識の元、合意形成をしていくほうが物事はうまく進められる場合が多いのではないか。
◆ 中島さん（アマゾンウェブサービスジャパン株式会社）
クラウドが前提としている”責任共有モデル”の考え方を理解する
責任共有モデルお客様と事業者で責任・統制範囲を定義する。クラウドの場合は、これを全ての前提にしてありとあらゆる前提で話す。なので、初めてのお客様はこの責任共有モデルから、はじめる。クラウドの中では、これが共通言語になっている。前提となる重要なこと。
”Everything fails all the time."
「すべてのものはいつでも壊れうる」
--- Werner Vogels, CTO AWS
責任共有モデルの下では、たとえば、
・複数のアベイラビリティゾーンにアプリケーションを配置することによって自然災害やシステム障害に備えるのは？
・データのバックアッププランを管理するのは？
これらは、いずれもお客様の責任。そしてそのことを繰り返しお伝えしている。
責任の共有は効果的。強みの領域におのおのが注力する。Design for Failureを前提として事業者／利用者のやるべきことへの集中をもたらす。これが責任共有モデル。
クラウドの設計・運用で取り組まれているWell-Architectedの取り組み概要や効能を理解する
ただ責任共有モデルだけを言われても困ると思う。Well-Architeectedの取り組みが必要。システム設計・運用の「大局的な」考え方とベストプラクティス集（アンチパターンもある）。
Well-Architeectedには5つの柱がある。「運用の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コストの最適化」あくまでも設計”原則”なので、実装の詳細やアーキテクチャーではない。
もっとも共有したいのは、一度だけではなく、定期的に繰り返すことが重要。障害が生じた際にも発展的な会話をしやすくなる障害を予防するノウハウがお客様社内に蓄積される。レビューの進め方に秘訣ありホワイトペーパーで3ページに渡って解説している。
Well-Architeected レビューのポイント
・レビューは「誰も責めない」アプローチで行う必要がある
・レビューはワークロードのライフサイクル中に複数回実施する必要がある
・レビューを実施する場合は、全ての適切な関係者がその対話に参加できるように手配する
・アーキテクチャの構築に携わったチームメンバーがW-Aフレームワークを使用して継続的にアーキテクチャをレビューする
・本番運用前にもレビューを行う
クラウドは新しい機能がどんどん加わる昨日までのアンチパターンが、今日からアンチパターンではなくなる、になる。
すなわち、クラウドの世界ではWell-Architectedの取り組みにより責任共有モデルに基づくお客様ワークロードの設計・運用の継続的改善を推進する。
◆ 吉村さん（SBクラウド株式会社）
発表の立場は、クラウド事業者（Alibaba Cloud）、クラウドリセラー、中国に詳しい会社。
ホワイトペーパーの一番最初のページは「責任共有モデル」。
サービス障害が起きているか知る術は、各社バラバラ。各社に特徴があって一長一短。例えば、
・サービスのステータス可視化する（PULL型。履歴もわかる）
・障害情報の速報連絡をしっかり対応する（PUSH型）
ユーザー側に対応してほしいのは、「セキュリティパッチ」「アップデート適用判断と実施」。
これはどちらが対応すべきか？
・脆弱性の情報
・サービスの変更、アップデート情報
・管理ポータルへの不正ログインリスク
クラウドサービスの運用は情報感度が重要。丁寧に情報を教えてもらいたい、という人もいる。通知が英語メールだけ。管理ポータルへの不正ログインのリスクはユーザーでアカウント管理が適切にされるべき。しかし、クラウドサービス提供側がMFA、SSO、アクセス制限、などは用意しないといけない。
中国案件のトラブル事例
Great Firewallに対する誤解とあいまいな説明。オフィシャルな仕様はどこにもない。頻繁にアップデートがある。そもそも「Great Firewall回避サービス」は中国に存在しない。
複雑化していく各国のデータ保護規則。日本語で情報頂戴、と言われる。
すべての国の規制をカバーできる人材やアーキテクチャーはない。海外のデータ規制✕クラウドアーキテクトを提供できる会社は少ない。
中国の法律的に問題ないかアセスメントして。と言われる。
法令対応の責任を誰が負うのか。情報提供だけなのか、有償のアセスメントか線引が曖昧。
APCのパーカーは好評だった
ネットワークの運用自動化・トレーニングサービスと、日本リージョン初のCPSP認定を取得したエーピーコミュニケーションズの強みの一つである”ネットワークセキュリティSI”に関するプロダクトを出展。当日にスタッフが着ていた黒地に黄色のデザインのパーカーはかっこいいと好評だった様子。
ご興味がありましたら、上記のページよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？