(公開日2018年2月3日)。2018当日の内容は以下にまとめられている。紀尾井カンファレンス)。Japanの技術的な取り組みに関して知ることが出来、とても豪華で楽しいイベントだった。聴講セッションについてのメモとか所感などをまとめておく。Japanのデータセンター内でのネットワークインフラのお話。聞きたかったセッションだった。Jaoanのネットワーク概要について。インフラ技術3部というところが35名弱のメンバーでプロダクションのネットワークを支えているとのこと。具体的には、CDN、バックボーン、データセンター内のネットワークまで全て。管理しているネットワーク機器は7000台超え。データセンターは東日本・西日本それぞれで複数持っていて、東西でASを1つずつ保持しており、BCPを取れるようにしているとのこと。米ワシントンにもデータセンターがありASを持って管理しているらしいがワシントンのデータセンターはActapio社が運用しているとのこと。外部からのトラフィックを(Noth-Southトラフィックと呼んでいるそう)、これは増加傾向にあり、GYAOやニュースなどの動画トラフィックがメインで500Gbps超え。外部トラフィックの増加に対しては機器のインタフェースの増速やより高スペックな機器を使うなどのスケールアップにより対応してるとのこと。データセンター内のトラフィック(East-Westトラフィックと呼んでいるそう)についてはNoth-Southのトラフィックよりさらに多く、全拠点合わせて10Tbps程もあるそう。Networkの導入を進めているとのこと。規模の大きさに単純に圧倒された。それに対応するためのCLOSのアーキテクチャはまだ詳しく理解できていないので以下の資料やブログなどもよく読み込んでみようと思う。Jaoanのデータセンターネットワークの取り組みについてのお話が続いた。Japanに限ったことではなく、FacebookやMicrosoftもそういう傾向があるとのこと。Japanとしてはこれらをベースにうまく活用していこうとしているとのこと。具体的なネットワークに対する取り組みに関してFacebookとの比較していた。Facebookと比較しているのはFacebookが情報をオープンにしているため。Networkを推進。Securityのため、コアスイッチにACLを設定すると同じセキュリティポリシーでないと構築できない。Network上には設置できないという問題がある。内部通信もセキュリティ担保のため各コアスイッチにACLを多用しており最大で11万行。ツールによる自動化で運用はできているが、大量に入っているためスケールアップが難しい。コアスイッチからiptablesベースのACLシステムを構築して開発環境でテスト中。Securityではなくサーバのグループ単位で様々なセキュリティポリシーが共存可能。これにより柔軟なアクセス制御を可能にするBox/Chipメーカースイッチではなくホワイトボックススイッチについてのお話。OSを利用しているとのこと。NetworksとCiscoやWhiteboxはBroadcomで同じチップなので、チップのダイバーシティ(多様性)のためASICにも注目されているとのこと。汎用ASIC、カスタムASICのそれぞれメリットがあるため利用を検討しているそうで、例えば汎用ASICはBroadcomで安い、タイムリーにその速度のインタフェースが利用可能、カスタムASICは大量のACLの投入やTelemetroy(?)が可能、などがあるらしい。Fabricを組まれており、1つのOSではないので冗長性が取れているのがメリットらしい...より詳細には以下のブログに書かれているとのことなのでこれも読んでおこうと思う。BlogAutomation自動化について。Japanではネットワークに関する自動化、可視化については自分たちでツールを作っており、既存のネットワークについては自動化と可視化ができているとのこと。いったOSごとの違いを抽象化して可視化。Fabricのケーブルの配線ミスの検知は難しいとのこと。Fabricに特化しているそうで、採用している。intentベースはやりたい設定をコンフィグとして生成する、自前でできないものはカバー。Fabricを作っているらしい。ネットワークの話は以上だった。他社のネットワーク構成の詳しい話を聞ける機会は少ないと思っていたので、大規模環境でのネットワークの取り組みの話を聞けたのはとても勉強になった。CROSのアーキテクチャについては資料や過去ブログ、関連情報をみて理解を深めておこうと思う。デベロッパーネットワーク続いてサーバ関連のお話。キーワードとして全体最適化とOCPを挙げられており、それに関してのお話。サイトオペレーション本部というところが商用インフラの担当部隊で、データセンター、ネットワーク、ストレージ、サーバ、OS、インフラのツールやOpenstackなどのプライベートクラウドの基盤といったアプリケーションレイヤまで幅広く担当しているとのこと。全体最適化まずは全体最適化について。機種は80モデル以上、パーツ点数は20万点以上の環境で、担当メンバー10人1チームが2チームあり、それに加えて業務委託の方が数10名。トラブル・故障対応、分析を行い、業務委託の方は配線やラッキングなどの物理作業を行うそう。構成の検討サーバ台数が多いので、サーバ1台ごとに最適化するのではなく全体最適化してトータルコスト削減を目指しているとのこと。ある時期にSSDを購入する場合、容量が80Gとか120Gとかあるが用途等によってバラバラに買うのではなく、その時期に買う型番を決めておき、パーツ管理や問題・バグを引く頻度のリスクを削減しているらしい。内製のインストーラなどがうまく動くか、独自のOSがうまく動作するか、個々のデバイス付属のユーティリティが動作するか使い勝手が落ちていないか、物理作業、配線のしやすさ、ボタンの押し間違えなどが起こらないかなどを検証し、それぞれ点数付けして、各モデル・各ベンダーの比較表を作って判断しているとのこと。独自の保守フローがあるので各ベンダー、関係会社にできるか、提供していただけるか、ない場合は作っていただけるかなどを検討するとのこと。大規模サーバの統計的な分析を行ない、将来のサーバやパーツ選定時に利用しているとのこと。故障時のデータを管理したり、パーツの価格は適正か、市場ではどうかなどを確認できるようにしたり、CLIやBMC、データを取得するツールなどが使いやすいかなどを数値比較。OCP続いてOCPサーバのお話。現在、全体の80%程度は一般的な1U/2Uのサーバらしいが1000ノード程度OCPサーバを導入しているとのこと。ヤフオクで使っていたものを広告用に転用する)、ユーザ手動でパーツ選定やHW設計ができ、ベンダーの影響を受けず、使いたいものを使いたい時に使えるのがメリット。サーバベンダーやパーツサプライヤー、調達やデリバリーなどのサービスを提供しているディストリビューターの各社計30社程と協業しており、ラッキング業務のナレッジなどを提供したり、様々なパーツの故障率などに関する統計データを提供して、選定するパーツ等の話をしているそう。将来的には「自立したインフラ」を目指し、外部依存を無くして、Yahooが主体的に管理できるようにしていくとのこと。大規模インフラ環境におけるサーバの構築から運用までのノウハウが聞けた。機器選定における検証や分析などかなり細かくしっかりやられている印象でさすがだと思った。検証時の点数付けのポイントや分析データ管理などをどうやっているのか具体的なところが知りたかった。実際に導入されているOCPサーバが会場に展示されて、見ると小さくて扱いやそうな印象だった。Japanほどの規模とそこにいらっしゃるエンジニアだとOCPサーバのメリットも大きい気はするが、一般的には保守の面がかなりネックになりそう。全20名+αの人数で保守周りもどうやっているのか気になった。JAPANを支える開発基盤のお話。デベロッパーネットワーク以下のリンク先にある内容と類似のお話。Foundryを利用しているとのこと。vSphereの複数のIaaS基盤と組み合わせたり、DBや開発言語を利用できるのがメリットある。Cloudまた、PaaSで動くCI/CDとして以下のツールを利用しているそう。Foundryにもすでに機能化されているらしい。GitHub導入した目的としては、これまでの開発手法だと開発後の運用保守に手間がかかっていたため、PaaS上で効率よく開発できるようにし、より付加価値の高いサービスを開発できるようにするとのこと。FoundryのBuildpackという機能で共通化できるそうで、これらによって開発者の負担を減らしていくそう。30,000リクエストをさばけるような規模のクラスタを構築していくとのこと。FoundryのCredentialsという値を発行してプラットフォーム側に格納して有効化する必要があったが、これをcliツールで自動でプロビジョニングをできるようにし、開発者の負担を減らしていくことを目指しているとのこと。vSphereのほか、Bluemixなどの商用プロダクトとも連携できるというのは初めて知った。McKenty氏から複雑さと自律性についてのお話。英語セッションで同時通訳のレシーバーがあったもののなかなか追うのが難しかった。ある通り、最も重要なのは価値あるソフトウェアを早くかつ継続的に提供して顧客を満足させること。このためには自動化が不可欠。これは人を相手にしているからとのこと。Elder))」...いかなる戦術も眼前の敵には無力。複雑さについて簡単な問題とはケーキを作るようなもの。レシピさえあればできる。入り組んだ問題とはロケットを作るようなもの。複数のレシピが必要で、組み合わせる必要がある。複雑な問題とは子育てのようなもの。レシピはなく、突発的な問題が起こる。半自律型のチーム半自律型のチームとは。チームがいろんなことを試している。間違っていても良いという感覚が重要。それが必要かを全員が分かっており、素早い意思決定ができる。組織は完璧を求めるべきではない。「半」自律型であることが重要。開発者だけで組織されたチームは効果を発揮しない。実験するマインド継続的に何かをするためには実験を行い続ける必要がある。どんな計画であっても敵の前では無駄。思い通りにはいかない。人は思い通りには動かない。人と貴方たちは常に対立している。完璧な計画なんてない。必要なスキルの変化コードを書いたり読んだりだけでなく、人の話を聞く、コミュニケーションをとる、振り返る、反省することも必須。ツールを使うのではなく、仕事の仕方を常に学び続ける。盆栽や俳句では、観察者と観察者の距離を短くしようと、不要なものを捨てて調整する。聞き取れなかった部分もあって見返すとよくわからないけど、ITエンジニアが人を相手にしたり複雑な問題に取り組むにはコードの読み書き以外にも多様なスキルが必要ということなのかと思った。Geekにも似たようなことが書かれていたと思うけど、物事をよりよく進めていくためには一緒にやる相手のやっていることを理解して耳を傾けて歩み寄ることが重要なんだと思っている。Japanでのk8sの利用事例。100以上のサービスを全てコンテナ化するためのコンテナ実行環境としてk8sを検討。TrendsでもOpenStackを抜き、DIAMOND&PLATINUMスポンサーにも世界トップクラスのIT企業が名を連ねていることから各社k8sに力を入れていることがわかる。Japanもk8sの本格導入を開始したそう。Serviceを利用してすでにズバトクのサービスでプロダクション環境で稼働しているとのこと。Japanの完全子会社。ちなみにZコーポレーションとは別会社とのこと。技術で新しい世界へシフトする。JAPANMコンテナ化以前のCI/CDリポジトリへのpushは自動化できていたがデプロイは手動だったとのこと。機能追加やパッケージが増えたりデプロイにかかる時間が増大、さらにアクセス増によるVMの増加でその運用管理コスト増大・故障時の対応増大...などなど、環境維持コストが高まってきた。開発に割くリソース確保が可能になったとのこと。Serviceの仕組みや機能の紹介。kubernetes導入で解決しないこと、起こる弊害。ノード(VM)の追加。約3ヶ月ごとにリリースされるkubernetesのバージョンアップ。コンポーネントの管理。Japanのような数万台規模の環境でKubernetesを手動で管理するのは現実的ではない。これらKubernetesの問題を解決しないことを解決するためのKaaS。k8sの管理コスト削減したりk8sクラスターを払い出すフルマネージドのツールとのこと。クラスタの追加は、開発者がKaaSに対してクラスタを追加するというリクエストを送ることで、YahooのIaaS(OpenStack)から必要なコンポーネントを作成され、社内のDNSにクラスターのドメインを登録まで行われる。他、構成を変えたり複数のクラスターを作ったりもできるOpenStackのフレーバーを変えることもできるとのこと。オートヒーリングや水平スケールなども運用工数削減のための機能がたくさんあるらしい。運用工数削減のニュアンスの言葉がよく出ていた気がする。Kubernetesは使ったことなく、Kubernetesクラスタの運用の大変さを味わったことはないけど、クラスタというだけでやばそうな気がする。Podなどの単語もその場ではわからなかった。いうか今も詳しくわかってない。そんな程度の知識しかないのでまずはKubernetesを触ってみるところから始める必要がありそう...KaaSは最初から導入するのではなく、Kubernetesの運用が手に余るような状態になってきたところで使うイメージなんだろうか...また、会場の中でもk8sを使っている方はほとんどいないかった。デベロッパーネットワークブランディングの技術についてのお話。Japanのプロモーションの紹介。2013年9月に行われた「さわれる検索」というプロモーション。インターネットで送れるものは視覚と聴覚。3Dプリンタの登場により触覚も送れるのでは?という発想の元、さわれる検索というものを開発。3Dデータベースを検索してそれがアウトプットされるというサービス。コードがGitHubで公開されていてると言ってたような気がして、確かに過去のプレスリリースでもそんなことが書かれていたけど探したけど見つからなかった。JAPAN2017/3月、3.11から6年、東京の人々が3.11を思い出すための広告。インターネット20年の歴史の絵巻物。JAPAN公式キャラクターの宣伝動画。若年層に弱いので親しみやすいキャラクターを作成。好きになってもらうか。選んでもらえるかの心理制御が大事。