扱っている方を集めてのクローズドなラウンドテーブルの第1回が開催されました。@keisuke69さんにお誘いいただき登壇させていただきました。今回の資料を作るきっかけを与えていただき、本当にありがとうございます。当日参加して下さった方もありがとうございます。今回は、ラウンドテーブルで用いた資料と、グラニのインフラの基本的な考え方を紹介します。AWSグラニは3年以上に渡りAWSでインフラ環境を構築しています。当時と現在では、大きくインフラ構成が異なります。したことであり、よりシンプルにすることの追求です。構成を公開するのか今回の構成は、かなり踏み込んだ部分まで公開しています。グラニのインフラ構成を公開したのは、自分達の現状の整理と戒めを強く意識しています。過去もそうですが、現在のインフラ構成にも多くの不満があり直したいことが山積みです。直すにあたっても、そもそも私の考えが間違っていることが非常に多い自覚があります。資料の補足と現状の理解を確認することを兼ねて少し現在の考えを書きますが、この資料や記事を読んでいただいた素敵な皆様がおかしいと感じられたことをご指導いただけると本当に嬉しいです。思い浮かべることが多いと思います。浮かべる方も多いのではないでしょうか?私は、それぞれのデザインパターンを次のように大雑把に捉えています。プラクティスパターン集インフラ環境をDisposable(いつでも捨てられるよう)にする。これを実現するためにAWS上の構成変更を躊躇わず、マネージドサービスを積極的に利用し、インフラ全員がコードを書いています。巷に溢れる優れたサービスを無差別に採用はできません、自分達にあったサービスを選択するための原則がないとすぐにカオスな状況に陥ります。かぎらず、パブリッククラウドにおける大原則であることが多いように思います。そのための手法も多く公開されています。docs.aws.amazon.comazure.microsoft.comグラニも同様に失敗しても再施行によって成功する構成を目指しています。*2失敗時の処理方法を共有するのではなく、もう一回やればいい。このシンプルさは失敗に対する心理的障壁を下げるだけでなく、チームに対しても単純で伝えやすいです。Patternグラニのインフラは、インスタンスを1台たてるのも100台立てるのも構成方法と処理時間に大きな違いがないようにしています。あり、スケーラビルティに大きく寄与すると思っています。インフラは多くのミドルウェアが動きます。*3自分たちのコードもその1つです。外部に寄せるようにする。自動デプロイ/再デプロイが高速、容易な場合はその限りではありません。利用できないかまず検討しています。すれば、全サーバーの構成が速やかに自動的に変わるというのは楽なものです。パターンを用いてることで、全て同一構成に揃うようにしています。https://aws.clouddesignpattern.org/index.php/CDP:Stamp%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3この辺は過去にも記事で書いたことがあります。適用するだけで構成しています。出るのを心から待っています。リリースされたらすぐに乗り換えて、全サーバーコンポーネントを一新します。違いますが、基本としている要素があります。先日のセッションと公開した資料の中で、「何度も、素早く繰り返すこと」(高速なイテレーション)を重視していることを述べました。かかっていては繰り返し自体が困難です。一回の施行は高速に、そして短いスパンで繰り返せることを目指しています。何でも速さが正義ではありません。頻度との兼ね合いで、一日1回しか実行しないなら数分、数秒に大きなこだわりを出しても仕方ないと思っています。副作用を伴う改善は極力選択しない「課題A」を改善するために、「回避不可能な別の課題B」を生じる。そんな改善は選択しないように気をつけています。限定的だったり無視できるようなデメリットなら採用することが多いです。短期的にデメリットがあっても、すぐに改善するとわかっているなら課題の大きさによっては待たずに即採用もあります。*8大事にしているのは、「根本の問題がなんなのか、原因を分析」することです。その場ですぐに解決できなくても後日ヒントや解決策に気づけるように意識づけています。変更できないかいつも考えています。積極的に採用しています。利用コストは当初と比較して劇的に改善しました。今も、不定期に構成を見なおして改善できないか検討しています。自動化を常に考慮するマネージドサービスを導入する際は、自動化できることを強く評価しています。Webhook、APIを含めて、サービス間連携できることが自動化手段を提供しているかどうかは重要です。APIが公開されていれば問題とすることがあまりありません。ウェブコンソールを使って最後にEC2を立てたのは3年前です。経由で作成しかしていません。一年以上前に切り替えました。1秒で終わるようにできたのは体感できるインパクトが大きくよかったと思っています。おけるシンボリックリンクの重要性は極めて高く、インフラ構成を「柔軟、簡素」にできる可能性が高いのでぜひ検討してください。発表を見た時に、ほとんど同じ発想だったのでどこの環境でも同じことを考えるのだなぁと思い、ブラッシュアップのため参考にさせていただきました。github.com資料も非常に分かりやすかったので、セッション資料でも参考にしています。フル活用できるようになっています。利用しますが、ただのツールです。ワンライナー、補助スクリプトがメインで長大なコードは次々とC#にリプレースされています。構成図の見直し今回は、ヴァルハラゲートの構成図でしたが、最初期からみてどんどん変わっていっています。変化は大事だと思っています。停滞はサービスの死に直結します。変化の記録と公開も同様に大事にしています。時系列で並べて見ます。構成図にない変化がかなりあるのですが、ここでは触れません。構成図自体も変化しています。Visio、昔から使っていますが、ついにトドメを刺せました。だれでも直感的に使えて再利用も共有も可能。そんなサービスだと思います。十分に構築できると考え実践する努力をしています。AWSにロックイン、ということもよく耳にしますが一切そんなことはありません。移行できる体制でもあります。各リソースの強力、安定さからです。グラニのインフラが目指しているのは、Windowsでうんぬんより、ユーザーにサービスをよりよく楽しんでもらえることです。そのためにできることをチーム全員が積極的に挑戦しています。共有するという文化から始まり、多くの面でインフラのトレンドを突き進んでいます。新しい考え方、手法にはサービスがより良くなることが多く秘められています。できないということは誰も言っていません、だから採用する努力をしています。あ、あと、グラニのこんなインフラを変えたい、もっと良くしたいとお考えの方をインフラ一同心からお待ちしています。したいとなると、おおむね選択肢は次の3つ...2019-01-052018年を振り返って2019年になって4日経過しました。読者になるこのブログについて引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。