Don't try

Don't try

技術ときどきミートボール

目標たててみた

ちょっと出遅れた感あるけど、今年の個人目標たててみた。

「目標とは、状況によって適宜変更するものである」と思っているので(根性なし)、進捗状況によって変更はあると思う。

個人的には3月4月に錯覚資産になるような資格、具体的にはAWS SAPか、システムアーキテクト or 応用情報技術者 あたりを一つ取得しておきたい。。。 しかし、この時期業務でかなり手を動かして勉強しなきゃいけないことが多いので、パンクしないためにもあまり多くは望まないようにした。

もりろん状況次第では玉砕覚悟で受験はするかも(SAPは受けるだけで三万するのが痛い。1番欲しい資格なのだが) 。


  • 2月・・・AWS SAA(ソリューション アーキテクト アソシエイト)合格。

  • 3月〜5月・・・業務にともなってAWS、Vue.js、Pythonあたりの勉強を追い込む。 アウトプットとしてECS、Lambda等を利用したSPAを個人開発予定。

  • 5月〜7月・・・小学校から高校の数学までを総復習

  • 8月〜9月・・・Coursera機械学習コース受講

  • 12月・・・AWS SAP(ソリューション アーキテクト プロフェッショナル)合格。


この中でもCourseraが一つ浮いている感。

私は基本的にはWeb開発者なので、正直機械学習を学んでもすぐに実務に役立つものはないと思っている。

ただ、それでも学ぶのは、将来的なCS(コンピュータサイエンス)学士取得のための力試しの面が大きい。

社会人でCSの学位取得を考えている人は多く、こんなQiitaの記事もあったりする。

働きながら取得可能な情報系学位の大学一覧【社会人】 - Qiita

取得したい理由は人それぞれだが、私としては、

①体系的にコンピュータサイエンスの知識を身に着けたい

②自分のエンジニアリング能力の客観的証明になるような資格が欲しい(早い話、海外でも生きていけるようにビザの取得に有利な資格を持っておきたい)

というところだろうか。

個人的にUniversity of the People のComputer Science または、帝京大学理工学部情報科学科通信教育課程を考えている。

UoPeopleの場合、課題はすべて英語で読み、アウトプットも英語を使うことになるのが魅力でもあり心配点でもある。アメリカの大学なので課題も多いとか。 できればここでいきたいところだが。。。

まあ学位もいいが、あくまで本業でしっかり力を発揮した上で今年1年上記の目標達成目指して頑張りたい。

ECS運用に役立ちそうなものまとめ

ECS運用に便利な機能まとめ。

経験が浅い自分のような人は、ついつい長期的に運用する観点を忘れてしまいがちです。

細々とした設定ファイル書いたりするより、「早くモノを作りたい!」の気持ちが勝つのでしょうがないけど。。。

最近は未経験者がポートフォリオでECS使ったりするのもあるあるらしいですが(スゲェ……)、

運用的な観点からいくつか機能を追加すると、ライバルに差をつけられるかもですね。

モニタリング

CloudWatch logs

連携することにより、簡単にログの収集が可能。

FireLens

Fargate環境で利用可能なログルーティング。

Firehoseと連携しCloudWatch logsのみではなく、S3やRedshift等への転送が可能。

AWSから「Fluent Bit」のコンテナイメージが提供されているため、ECSのタスク定義の中にアプリケーションコンテナと共に設置し、コンテナ経由でログを収集可能。

ECSの仕様として、コンテナごとにログドライバーが一つまでとなっている。

そのため、Fluent Bitを設定し、CloudWatch logs とS3 の両方、または種類ごとにどちらかに一方のみの出力とするのがベター。

※ ログの出力先の分岐にはFluent Bitのコンテナイメージのカスタマイズが必要。

メトリクス

メトリクスとは「定量的な指標として定期的に計測・収集される動作データ」。

「CloudWatch メトリクス」と「CloudWatch アラート」でアラート通知なども可能。

トレース

アプリケーションの内部処理の呼び出し、各サービス間のトランザクション情報などを取得。

X-Ray

X-Ray」で収集可能。

タスク定義にX-Rayコンテナを同梱し、アプリケーションにX-Ray用のコーディングを施すことで利用可能。

ECSのコンテナアプリケーションからX-Rayにトレース情報を書き込むには、IAM管理ポリシーの「AWSRayDeamonWriteAccess」がECSタスクロールに付与されている必要がある。

またECSタスクがプライベートサブネットにデプロイされている場合、インターフェース型のVPCエンドポイントを設置する必要あり。

メンテナンス

ECR

コンテナイメージのリポジトリ

裏側ではS3が動いているため、ライフサイクルポリシーの設定で一定の条件での保存と破棄可能、かつ高い耐久性を持つ。

タグ付けでリソースを管理する。

踏み台設計

パブリックサブネットにEC2を置く

通常のパターン。SSHで接続。

EC2運用の手間がかかる。踏み台がインターネット向けに公開されるリスクもあり。

セッションマネージャーを利用する

セッションマネージャーを利用することで、コンソールから接続できる。プライベートサブネットに置いても接続できるため、踏み台がインターネット向けに公開されるリスクを減らせる。

ECSで踏み台を設計

タスク内にSSMエージェントを設置することで、セッションマネージャーから接続できる。

インスタンス管理等の手間が省ける。

参考

AWSでECSを利用したコンテナ環境を設計、運用するうえでとても参考になります。

ECSの基本概念

ECS (Amazon Elastic Container Service)

ECSはフルマネージドなコンテナオーケストレータ。

オーケストレーションサービスのため、コンテナを動かす実行環境のサービスではない。

コントロールプレーン(コンテナの管理機能)

タスク(Task)

一つ以上のコンテナから実行されるアプリケーションの実行単位。

タスク定義(Task Definition)

タスクをJSONで定義するリソース。*1

imageやその他のリソースなどを定義する。

サービス(Service)

指定した数だけタスクを維持するスケジューラー。

ロードバランサーと紐付ける。

クラスター(Cluster)

上記のサービスとタスクを実行するグループ。

ECSのコンテナ管理概念の関係

タスク定義によってタスク(アプリケーション)が生成。

サービスがタスクの管理を行い、

タスク×サービスを関連付けし実行するグループ=クラスター。

データプレーン(コンテナの実行環境)

Amazon Elastic Compute Cloud (EC2)

EC2。AWSを代表するサービス。

コンテナホストとして利用した場合、EC2インスタンスの運用コストがかかってくるため手間がかかる。

柔軟なサービスなので、細かい要件に合わせて運用したい場合はアリ。

AWS Fargate

ECSとEKSで動作するサーバーレスコンピューティングエンジン。

コンテナホストの管理が不要。ホストのインフラがAWSによって常に最新状態に保たれる。

利用者はアプリケーションの開発および機能追加に注力できる。

ただ、EC2より若干価格が高い。

利用者がインフラに介入できないため、OSリソースを詳細にチューニングする必要がある場合などは不都合になる。

リポジトリサービス

Amazon Elastic Container Registry(ECR)

コンテナイメージを保存、管理。

ECSと連携し、コンテナイメージを取得→立ち上げなどが可能。

*1:今のところタスクとタスク定義の関係は「インスタンスとクラス」「Dockerfile と docker image」の感覚で捉えているけど、問題ないのかな。。。

Docker ver1.13 以降のコマンド変更メモ

・イメージのビルド/

$ docker build => $ docker image build

・イメージの一覧/

$ docker images => $ docker image ls

・イメージ削除/

$ docker rmi => $ docker image rm

・イメージタグ追加/

$ docker tag => $ docker image tag

・イメージをプッシュ/

$ docker push =>$ docker image push

・イメージをプル/

$ docker pull => $ docker image pull

・コンテナを起動/

$ docker run => $ docker container run

・コンテナのログ確認/

$ docker logs => $ docker container logs

・コンテナに対してコマンド実行/

$ docker exec => $ docker container exec

・コンテナを停止/

$ docker stop => $ docker container stop

幼年期の終り

独学でポートフォリオを作成してエンジニア転職。

しかし、アウトプット不足なまま、転職から1年が経過が経過しようとしている。

どこまでが「駆け出しエンジニア」なのかは分からないが、

「すみません、不勉強でよく分かりません、教えてもらえますか?」

が許されなくなって来る日も近づいている気がする(もちろん、分からないことを素直に聞く態度はいくつになっても大事だけども)。

というわで年も明け、区切りもいいタイミングでもあると思うので、今日からここで学んだことをまとめていけたらなぁと思います。

細々としたメモや雑記はここに書いていきます。 ある程度有益な知見だと思えるものがあれば、Zennのbookとか、あるいはQiitaなんかにアウトプットできたらいいな。