Developers.IO TOKYO 2019参加レポート

先日Developers.IO TOKYO 2019に参加してきました。
技術の話から、チームマネジメントの話まで非常に盛りだくさんでした。
私が参加したセッション内容をまとめます。

ハイブリッド/マルチVPC環境を構成するためのAWSネットワーク完全理解

発表資料

概要

複数なVPCを合わせて使うクローズドなネットワーク環境

ポイント

複数環境の通信を適切に制御するルーティング
ネットワーク的にIPで繋がらなければ如何しようも無い

Key Component

• IGW
• VGW
• PCX

制約

VPCをホップする通信は不可能
全てのVPC・オンプレミスを1対1で繋ぐ必要がある（フルメッシュ型）

After Transit Gateway

• ハブ型での相互接続を実現するサービス
• ルートテーブルが編集可能

料金

VPC1個アタッチメントするごとに$0.07/hour

TGW

• 1つのTGWに複数のルートテーブルを設定可能
• 1つのアタッチメントがアソシエーションできるルートテーブル は1つのみ
• 通信先相互で同じルートテーブルに紐付ける必要はない

所感

最近は業務でVPC周りを触っており、知見がかなり深まっていたところなので聞いていて面白い内容だった。
他社のネットワークや、AWSアカウントを跨いでのプラベートネットワーク構成が多い構成の場合には非常に役立ちそう。

エンジニアも知っておくと得する、デザイン組織とデザイナーマネジメント

発表資料

デザインと市場

• ビジネス系の話でも結構デザインの話が出てくる時代
• カンファレンスでもデザインにおいてセッションに参加する人が多いくらいの市場感
• iPhoneが出たあたりから、「アプリを作ってビジネスにする」→「アプリにデザインを組み込む」という流れができてきた

デザイナーと仕事をする時の注意点

「まぜるな危険」

• デザインの種類を混ぜない
• デザイナーの特性を混ぜない

デザインの種類を混ぜない

ビジネスの中では 見た目 = デザイン とは限らない

• 見た目: UIデザイン、グラフィックデザインなど
• 見た目じゃない: UXデザイン、サービスデザイン、組織デザインなど

両方できるデザイナーは少数派。そのことを理解した上で「誰に何を任せるか」を考える。

デザイナーの特性を混ぜない

デザインの8割は理屈
アートを大事にするデザイナーと論理を大切にするデザイナーに分かれる

デザイナー採用時にマトリクスを思い出し、どこに当てはまるかをイメージ。
（スライドP29参照）

• 理想実現型(感覚的 x 挑戦的)
• 成果追求型(論理的 x 挑戦的)
• 共同作業型(感覚的 x 保守的)
• 実務遂行型(論理的 x 保守的)

デザイナーあるある

• 売上や生産性の話をされてもやる気が出ない（理想実現型）
• ディレクションの仕事ばかりになってきたのでやめたい（理想実現型、成果追求型、実務遂行型）
• デザインに興味がない人の指示で仕事をしたくない（理想実現型、成果追求型）
• 凡ミスがなかなか減らない（理想実現型、成果追求型）
• 残業がないけど運用ばかりでつまらない（理想実現型、成果追求型）
• 他のデザイナーと合わない（全ての型）

ちゃんとデザイナーの組み合わせをケアしながら組織を作っていかないと、辞めていってしまう。

デザイン組織の役割

デザイナーの違いを理解し、組織の中で活躍できるようにする

デザイン組織成功のコツ

デザイン組織とビジネス組織の境界でハレーションが起こりやすいので、境界を整えると良い
noteにて「デザイン組織を構成する4階層モデル」というのを出しているので読んでみると良い

所感

エンジニア組織に当てはめても同じ状況を見て取れそう。
ビジネスとのバランスを見ながら「この人にはこういう話し方をすれば良いんだ」とか、「この人はこういう仕事をお願いすれば良いんだ」などをうまく分けていくことでより良い組織づくりができる気がした。

カルチャービルディング ~世界最強のAWSエンジニア集団の作り方~

発表資料

企業におけるカルチャー

• 時間をかけて積み重ねてきた、意識的あるいは無意識的に共有されている価値観、行動規範
• 企業理念だけではカルチャーはできない
• 企業理念を「意識しながら」過ごしてきた時間が結果としてカルチャーになる

なぜ企業カルチャーが重視されているのか

変化のスピードが激しい時代
変化のスピードに追従できないと生き残れない

求められる企業の姿

• 変化に合わせて変革し続ける
• 失敗を恐れず打席に立ち続ける
• 学習し続ける

Building a winning culture

文化は競争上の優位性の最大の源

クラスメソッドのカルチャービルディング

まず最初に、部の理念を作る

企業理念をブレイクダウンして、部のビジネスにマッチした理念に落とし込む
「オープンな発想と高い技術力によりすべての人々の創造活動に貢献し続ける」
↓
「AWSに関する圧倒的な量のノウハウを用いて、AWSインフラを安く早く構築し、AWSのことを丸っとお任せしてもらうことで、顧客のビジネスに貢献する」

最低限組織に必要なもの

下記をconfluenceにて言語化している。

行動指針

理念を実現するために行動を規範する

• セルフマネジメント
  • 自由に提案しオーナーシップとリーダーシップを持って自分で遂行
  • 仕事も生活も勉強もプロアクティブに
  • 相談には乗るけど指示はしない
  • 許可を得るな、謝罪せよ
• アウトプットファースト
  • 他人が見れないインプットは成果とみなすことが出来ない
  • 全てのアクションはアウトプットによって評価される
  • 案件はもちろん、登壇、ブログ、執筆、社内WikiでもOK
    形は色々あって良いが、何かしら見える形にすることが必要。

人事考課の仕組み

• 四半期ごとに部門長とメンバーで1時間の1on1
• Guideにしたがってヒアリングし、来季の目標を設定

給与の基準を作る

• 職種ごとに求められる能力を明文化
• 職種ごとの定量的目標を明文化
• 元々の給与が、ほぼ全色の条件に引きずられて決定していたので、2年かけて適正なバランスまで調整

採用基準を作る

• 理念と行動指針にしたがった採用基準を制定
• 採用基準通りに採用すれば、理念や行動指針に従わない人は入ってこない
• 採用は企業カルチャーを醸成し維持するための最も重要なフィルター

採用の最悪手

• 仕事に合わせて人を取る
• スキルだけ見て、仕事のスキルセットに合わせて採用してしまうのは最も危険

→ その仕事がいなくなった時に、その人のカルチャーがずれていると他の仕事で活躍できない

組織拡大

最近は毎月10名前後が入社している
カルチャーをどう維持するか？

組織構造のリデザイン

• 業務内容によって部を分割
• チーム作成ルールを定義
• 頻繁にコミュニケーションを取るチームは5人以下に抑える

情報共有のデザイン

組織が細分化されると縦割りになりがち

コミュニケーション手段の選定

朝会など、情報共有を行うためのコミュニケーション手段を確定する

ミドルマネジメントの育成

• マネジメントに興味を持っていたり、素質があると思われるメンバーをピックアップ
• 積極的に権限を委譲し、ミッションを提示
• カルチャーの意識合わせを常に行い続ける

マネージャー=ただの役割

• マネージャーはマネジメントという仕事をする人
• 権利ではないし上下関係もない
• マネジメントにチャレンジしてうまくいかなければメンバーに戻れば良い
• メンバーに戻りやすくする雰囲気を作る

キャリアパスの設計

3年後や5年後に活躍できるように、エンジニアのキャリアパスを作る

さらなる組織拡大

360度評価の導入

• 人事考課がマネージャーガチャにならいように、評価の目を増やす
• ランダムに複数の同僚を評価
• 結果はあくまでマネージャーが参考評価として使う

人事部の立ち上げ

これまでは各部にて1次面接を実施

カルチャーの明文化

暗黙知を形式知に

カルチャーフィットの確認と是正

• モチベーションクラウドの導入
• カルチャーにフィットしていない期待値はコントロールが必要

今後発生するだろう課題

• 300人が1000人になってもカルチャーが薄まらない組織づくり
• カルチャーの縦割りを防止
• ミドルマネジメント不足

所感

「企業の作りたいカルチャー」を常に意識しながら動いていることが大きなポイントだと思った。
特にアウトプットファーストはClassmethodの大きな1つのカルチャーとして、カンファレンスで発表したり1日に10本以上の記事が独自ブログに上がっていることからも感じ取れた。
また、「マネジメントにチャレンジしてうまくいかなければメンバーに戻れば良い」という小さな失敗を恐れないカルチャーがすごく良い。失敗した時にフォローできる空気感が大事なのでしょうね...

LINEサービスを活用した新しい顧客体験を創造する

発表資料

O2OとOMO

O2O: Online To Offline

デジタルからリアルの世界へ送客
ex.スマホアプリを使ってクーポンを受け取る

OMO: Online Merges with Offline

オンラインもオフラインも一体
顧客が購入するときに、一番最適な選択をできるよう、オンラインでもオフラインでも考えましょう
ex.ソファに座って口頭でフードデリバリーを注文すること

OMO発生条件

• モバイルネットワークの普及
• モバイル決済浸透率上昇
• センサーが高品質で安価で手に入り、遍在する
• 自動化されたロボット、人工知能の普及

事例

Mobike

レンタル自転車サービス
QRコードにて決済、返却が完了
「この年代の人はこういうところによく行く」とか「この辺代の人はこのエリアをよく通る」といったデータ分析が可能になる

Luckin Cofee

モバイルオーダーアンドペイ
店頭受け取りかデリバリー
弊社でやってることに近い

LINEを使った新しい顧客体験

Mobile Order and Pay

数タップで注文 ~ 決済までLINEで閉じる
Developers.IO CAFEというのを出してる
ウォークスルー決済を体験できる

Members Card and EC

アプリをダウンロードせずに使える

IoT

LINE ThingsでBluetoothを活用したリアルデバイス連携

まとめ

• インストール障壁がほぼない
• SDKにより開発工数激減
• 決済もLINE内で完結しセキュア

所感

LINEサービスを活用することにより、インストール障壁がほとんどないことは確かに共感。　　
アプリをインストールするだけでも顧客目線では結構面倒なので、サービスを展開する手段の選択肢としては今後も活用するメリットは大きそう。

障害に備えたアーキテクチャを考える「あの時何が起こった！？」

発表資料

8月23日 東京リージョン障害

冷却装置にバグがあり、障害

• EBSボリュームに深刻な影響が出たが、スナップショットを取ってなかったので普及できなかったり
• アプリケーションによっては、RDSやElastiCacheのIPアドレスをキャッシュしようとしていたため、何度もAZ-Aに繋ごうとしていたり

クラスメソッドブログサイトの管理者から学ぶ

障害時お手本のような対応だった

14:30 異常検知

EBダッシュボード確認
→ CloudWatch ALB ダッシュボード確認
→ ALBが怪しい

15:00 ALBのアクセスログから原因を調査

actions_executed: waf-failed が多発していることを確認
→ WAFが怪しい

15:20 WAF調査

WAFのメトリクスからアクセス集中の疑いを排除

15:30 暫定対処

ALBのWAF保護を一時的に無効化
→ 収束

ポイント

• 原因、複合的要因を1つ1つ着実に排除していく
• 原因を特定するためのメトリクスを取得できるようにしておく
• 障害想定と復旧手順を確立しておく

AWS Well Architected Framework

設計の原則
システムが最適かどうかを評価する「視点」を手に入れることができる

信頼性とは

• 障害から回復する能力
• リソースを動的に確保する能力
• 障害の影響を最小限にする能力

復旧手順をテストする

本番規模で繰り返しテストすることで信頼性を向上

障害から自動的に普及する

• CloudWatch → SNS → Lambda
  例: EC2 Auto Recovery

スペックの推計をやめる

• 自動でリソースを追加/削除 適切なスペックを維持

自動で変更を管理する

CloudFormationなどで、インフラに対する変更は自動化しよう

ベストプラクティスから考えるアーキテクチャ

3つの分野

• 基盤
• 変更管理
• 障害管理

(情報が多いため資料参照)

まとめ

• イベント発生時にシステムで何が起こっているか調査しやすいようにしておく
• オオカミ少年にならないように、必要なものだけ通知するように
• 99.9%シナリオをベースに普及アクションを自動化して稼働率を上げていく

所感

個人的にはまだまだ障害対応の知見が浅いので、こちらのセッションは非常に参考になった。
復旧手順を確立することも大事だが、「ソースコードを書くときも運用を考えたアーキテクチャを意識する」をすることも一つの大きなポイントな気がした。

ECSを活用したAWS運用自動化サービスの裏側を包み隠さず解説

発表資料

AWS運用と課題

今回は定常作業をテーマに

定常作業

• EC2/EBS/RDSバックアップ
• セキュリティグループの作成など

困りごと:

• 運用に忙殺され、将来に向けた改善に時間を割けない
• 担当者に依存した業務、その人に負荷が集中

トイルと運用自動化

「通常運用中のシステムに人手が必要なら、それはバグだ」

労働時間短縮、品質向上、コスト削減
自動化は対象の周辺で考慮すべき事項が多く、なんだかんだで難しい

opswitch

クラスメソッド製サービス

• EC2バックアップの作成
• セキュリティチェック
• リソースの止め忘れチェック
• RDSインスタンスの起動・停止

などを自動化。
これを活用することで、様々なAWSサービスの運用を自動化できる。

Apache Airflow

Python製ワークフローエンジン
Pythonkコードでワークフローをスケジューリング & モニタリングするプラットフォーム

事例

• Cloud Composer
• Astronomer Cloud

所感

コスト削減のためにAurora Serverlessが出ていたが、ワークフローの方もコスト削減を実現する上で色々と使えそうな気がした。
Classmethodのopswitchも、かなり多くのワークフローをサポートしているので、開発工数が足りない時とかは結構役に立ちそうなので一度広く見てたい。

AIOps: 運用に置けるAIの活用

発表資料

AIOpsの市場間

2018年〜2023年でマーケットとしては30%成長すると予測

定義

Algorithmic IT Operations
とされていたが後に
Artifical Intelligence for IT Operations
に再定義

MLOpsとの違い

• MLOps: MLを運用・改善する活動(MLを運用に活用することとは異なる)
• AIOps: AIサービスを応用してIT基盤運用における問題を分析・改善・自動化

AIサービス

学習モデルが構築されており、用途・できることがある程度決まっている。
必要なのはデータのみ。
イメージとしてはSaasに近い。

Operations

運用を指す

• サービス監視
• インシデント対応
• 運用体制やルール策定

What is

AIOpsは運用エンジニアが対応するIT運用領域をターゲットとしている。
AIサービスを応用してIT基盤運用における問題を分析・改善・自動化。

• パフォーマンス分析
• 異常検出
• イベントの相関と分析
• ITサービスの管理と自動化

Why is need AIOps

マイクロサービスの登場。
コンポーネントの増加やサービスの複雑化から、可視性や障害対応の難しさという課題がある。
モニタリングの領域だと、observabilityという考え方がある。
個人/人間の力の限界の登場が最大の理由。

課題と事例

パフォーマンス分析

Dimensional Dataとして多くのデータを取得し、観察する必要がある。
言うは易し、行うは難しと言う感じ。

活用事例

DATADOG

異常検出

オートスケールやコンテナ化により動的で短命になったシステムでは、個別に閾値調整や予測をすることが困難
アラートを受けてからのリアクションなスタイルでは常に対応が後手に

活用事例

• CloudWatch → Anomaly Detection
• mackerel → ロール内異常検知
• DATADOG → Anomaly Detection, Outlier Detection

イベントの相関と分析

大量のアラートがノイズとなり、本当に必要なものを見落とす

活用事例

• PagerDuty → Event Intelligence
  • 重複するものなどのノイズを抑制
  • MLを用いて関連アラートからインシデントに変換
  • 過去の類似インシデントから高いコンテキストを取得
• moogsoft + Systems Manager OpsCenter

ITサービスの管理と自動化

SLAやSLO, KPIがあるが、管理対象が増えて複雑化することにより、因果関係が不明確に

活用事例

• splunk → IT Service Intelligence
  KPIやSLAを設け、サービス状況を可視化

AIとOperationは相性が良い

• 学習材料となるデータが豊富
• 人間の限界をカバー
• 集合知の実現への一手

どう始めれば良い？

AIOps Platformを活用
目的を明らかにし、スモールスタートするのが吉

所感

業務でもEKSを取り入れ始めているので、CloudWatchのAnomaly Detectionなどは見てみる価値がありそう。
この辺りも、障害関連の知見が浅い自分にとっては非常に参考になった。

最後に

普段見ることができないようなお話しが多く、非常に濃いカンファレンスでした。
セッションによっては新し目のAWSのサービスの話とかしてたりするので、その辺りはクラスメソッドさんの強みをすごく感じました。
カンファレンスの当日の朝から資料がちらほらとUPされ始めていたのが非常にありがたかった...

なお、今回のカンファレンスの資料は下記にてまとまっています。
https://dev.classmethod.jp/report/developers-io-2019-tokyo-summary/