【レポート系】

Aws Summit Tokyo3日目の感想

最終日です。

基調講演は捨てるつもりで居たので、12:00〜開始
体の疲れは来ているけど、昨日のイベントで精神的には充実。

3日目参加した内容

12:00-12:40 AWSコンテナサービス入門

感想として非常に分かりやすかった!!
このブログでちゃんと伝えれなくて、本当に悔しい。

◾️コンテナとは?

まず、コンテナなど関係なく、システムを稼働するための構成としては、javaでいうと以下4点

1:ランタイム環境(Java Runtime Environmentなど)
2:外部ライブラリやパッケージ(画像処理ライブラリなど)
3:アプリケーションコード(xxx.javaなど)
4:設定ファイル(環境設定の記述 jsonなど)

しかし、環境差異などで
・開発はJava6
・ステージングはjava7
・本番はjava4
となった場合に、開発では稼働するのに、本番では動かないという状況が生まれる。

これを解決する案として生まれたのが「コンテナ」
さきほどのシステムを稼働するために必要な機能として
1:ランタイム環境(Java Runtime Environmentなど)
2:外部ライブラリやパッケージ(画像処理ライブラリなど)
3:アプリケーションコード(xxx.javaなど)
を一つに纏める。

設定ファイルをコンテナに入れると、各環境用にコンテナを作る必要があるので、実行時に設定ファイルを渡す形式で、各環境に適用を行う。

◾️Dockerとは?

コンテナを実行するためのエンジン。
オープンソースであるが、コンテナ=Dockerと言われるぐらい有名。

◾️VMとコンテナ

仮想化という意味でVMとコンテナが並べられるが
はっきりとした違いは
・VMはマシンを起動するモノであり(起動時間:1〜2分)
・コンテナはプロセスを起動するモノである(起動時間:数秒)
 ⇨複数プロセス(Apatchとphpなど)を同一コンテナに入れるのはナンセンス、それならVMで良い。

◾️コンテナイメージの作り方

2通りのやり方があり
1:DockerFileという定義ファイルで作成する方法
2:空のコンテナを作り、その中で設定作業をする方法

◾️コンテナの配置

コンテナの配置はsshで各サーバーに入り、コンテナイメージを格納したレジストリからpullする。

しかし1個なら良いけど、1000台あった場合にも手作業でやりますか?

これを解決するのがコンテナオーケストレーション

◾️コンテナオーケストレーション

コンテナオースケトレーションとして、有名なのがKubernetes、長いのでK8Sと略します。
開発者はコンソールにだけ命令を出していれば1000サーバーあっても平気ですし、オペミスもありません。

K8Sに対抗して生まれたのが、Amazon Elastic Container Serviceです。これも長いのでECSと略します。
K8Sと違う点はAWSサービスをコントロールできる点です。
LBやAutoScaringとの接続を容易にします

しかし、K8Sの利用者の半分はAWSのサーバーで稼働していることが分かりました、なのでAWSのサービスとしてK8Sを稼働させようと云うのがAmazon Elastic Container Service for Kubernetesです。略してEKSとなります。

では何故ユーザーたちはK8Sを選択しているかというと、ECSよりも設定の自由度が高いからです。簡素化したモノがECSと言えるかも知れません。

◾️レジストリ

Dockerイメージを格納するレジストリのAWSサービスもあります。Amazon Elastic Container Registry これは略してECR。
DockerにもDocker Hubというレジストリがありますが、場所が全世界にある訳ではないので、レイテンシーが発生します。
またECRの強みとしては可用性があることです。

例としてサーバーが1〜2台で稼働していましたが、急激なトラフィックで1000台までスケールアウトすると、増加分のDockerイメージを取得する必要があります。
この負荷に耐えれるレジストリが必要になるのです

◾️サーバーの子守はしたくない

コンテナで稼働しているとは言え、地盤となるサーバーの死活監視は必要となります。しかし、それは本来したいビジネスではない。
ではそこの管理をAWS側で一元管理して、稼働させたいサイズだけを指定すれば良いのがAWS fargateです。

コンテナ単位で最適化するので、サーバーを不必要に起動することがなくなります。

Fargetについては自由度を求めるか、ビジネスロジックのみに注力したいのかで変わりますが、サーバーの子守からの解放はすごいと感じます。

13:00-13:40 Kubernetes on AWS

上の講義をさらに詳細化した感じでした、省略します。
K8Sの詳細は勉強したいので、どっかで整理。

ワークショップがありますので、EKSの勉強したい方はどうぞ
https://eksworkshop.com/

14:00-14:40 サービスメッシュは本当に必要なのか?何を解決するのか?

◾️1つのサービス

「LB⇨APP⇨DB」という単純なサービスにおいて
APPが小さく・単純なモノであれば問題がないが
大きく・複雑なAPPとなると、障害が頻発してくる

・変更による影響の広さ
 ⇨数ステップの修正でもテスト範囲は広い
・モジュール構造の複雑さ
 ⇨いわゆるスパゲティコード化する
・非効率なスケール
 ⇨APPのある機能だけスケールしたいのに、全体スケールとなる。

◾️マイクロサービス

1つの大きなサービスではなく、小さく・細かいサービスとする考え

・変更による影響の範囲が限定的
・モジュール境界が分かりやすい
・独立したスケール

◾️利用者から見たマイクロサービス

マイクロサービス化しても利用者からすると1つのシステムでしか無いです。
このため、ユーザーが「遅い!」と感じた場合の原因調査については、関係する全サブシステムを確認する必要があります。

まぁ各システムで、ログを出してはいると思いますが、ログから調査をすれば良いですがログ出し方はマチマチだったります。

システム ログ内容
A 開始、終了、ユーザーからの情報(IPなど)、利用ブラウザ、アクセス時の負荷情報 、ステータス
B 開始、終了、ステータス
C 開始、終了(バグで嘘情報)、ステータス
D ステータスだけ
E ログ?取ってませんよ?

このようにログの内容が不統一で、システム全体を俯瞰するのには難しいです

◾️では共通関数を組み込もう

次に運用チーム提供で統一したログを出すために共通関数を組み込む考えが出ますが、、、

各チームから出る意見としては
・いやいや、十分ログ出しているよ!
・そんな時間ない
・工数は?
・GOの共通関数無いのんですけど!!
・共通関数が遅いのでタイムアウトする。。。。
と言われます。

運営チームからは
・JAva6から7にVerUPしたいけど、Aチームが6のままで切り替えれない
・こんな沢山の言語書けない。。。
・あのチーム共通関数入れてない。。。
となります。

◾️アプリケーションプロキシ

APPの前にプロキシとしてIN/OUTの通信情報を取得機能をサービスメッシュといいます。

有名なサービスメッシュとしてはenvoyです。
しかし、envoyもアプリケーションがデプロイされる度に再設定が必要になり、オペミスでログが取られない場合があります。
これを改善するのがAWS App Meshです。
App Meshを導入することでシステム全体の俯瞰したログ監視が可能となります。

しかし、本当にMeshが必要なのか?
無くても、共通関数でも良いのではないか?
必要な理由・不要な理由を考えることが重要と最後の言葉が印象的でした。

App Meshもロードマップがあるよ
https://github.com/aws/aws-app-mesh-roadmap

3日目総括

12:00-と14:00-に説明されていたAWSの原 康紘さんという方がいらっしゃのですが、一発でファンになりました
最近エバンジェリストという方々が居ますが、惹かれる喋り方をできるようになりたい!!

あとJTBで「AWS re:Invent」のツアーがあって30万ぐらいだったんですが、結婚してなかったら普通に行ってるだろうなぁと思う。
しかし仕事行く可能性もあるので、英語は勉強しておこう!!

関連記事

  1. 【レポート系】

    Aws Summit Tokyo1日目の感想

    Aws Summit Tokyoに参加してきました。3日間もあるの…

  2. 【レポート系】

    Aws Summit Tokyo2日目の感想

    当日に書きたかったけど、酔っ払ったので起きたら書いてます。疲れてい…

アーカイブ

PAGE TOP