SUZUKI, Masashi

これは  3-shake Advent Calendar 2022 10日目の記事です仕事の中でAWSで複数のアカウントを管理したいという要件あり、その中でAWS Control Towerが使えないかなと調べたものをざっくりと書いていきます。AWS Control TowerとはAWS Control TowerとはLanding Zoneを実装するためのAWSのマネージドサービスです。そもそもLanding Zoneって何って話になりますね。Landing Zoneとはセキュリティとコンプライアンスのベストプラクティスに基づきアーキテクチャ設計とマルチアカウント環境を管理する仕組みを指します。Landing Zoneは、下記機能から構成されます。アカウントの発行必要な初期設定の済んだアカウントを作成管理用権限の発行対象アカウントを管理するための権限を作成AWS ログの集約監査用ログをセキュアに一元保存ガードレールの設置実施してはいけない操作の禁止危険な設定の監視Landing Zoneの実装方法AWS Control TowerAWSサービスとして提供される Landing Zoneです。容易に利用可能ですが、カスタマイズするには制限があります。(必須のガードレールを外せなかったり)主にこれからAWSを利用する場合に利用できます。既存アカウントにも適用可能です。独自実装の Landing Zone自組織で独自実装するパターンです。自組織の方針に従って自由にカスタマイズできるのが強みです。ただし、自由にカスタマイズはできますが、自身でメンテナンスしないといけないので、コストはかかります。主に既存アカウントに適用する場合に利用できます。自組織でアカウント発行の仕組みや管理の仕組みができあがってる場合などです。そもそもなんでマルチアカウントにするのかAWSをマルチアカウントにする観点として以下のものが考えられます。環境の分離開発、テスト、本番を分離することによるセキュリティおよび統制の確保請求の分離部門やシステム単位でのコスト明確化権限の分離部門間での権限分離およびアカウントへの権限移譲複雑性の分離アカウントの目的を明確に絞ることで、構成がシンプルになるAWS Organizationsだけでもできることマルチアカウント管理するだけならOrganizationだけでもある程度はできます。むしろAWS Control TowerはOrganizationの機能を利用しています。複数AWSアカウントの一元管理Organization Unit(OU)の作成複数アカウントのグルーピング化AWSアカウントの発行Service Control Policyの作成、OUへの適用複数アカウントの一括請求AWS Control Towerだと何ができるのかControl Towerで提供される機能として以下のものがあります。Landing Zoneの提供AWS Organizationを使用してマルチアカウントを作成デフォルトでSandbox、SecurityのOUを作成AWS IAM アイデンティティセンターを利用したID管理を提供Account FactoryAWSアカウントのプロビジョニングの自動化設定可能なテンプレートを提供CloudTrailとConfigログの保存Log Archiveアカウント内のS3バケットに一元的に保存されるガードレールの提供必須と任意の観点の2種類と予防的と発見的の2種類の組み合わせがありControl Towerにより管理下のアカウントに適用される参考: ガードレールの仕組み予防的ガードレール(Service Control Policy)禁止されたアクションの実行が拒否される仕組みControl Tower管理下のアカウントは必須の予防的ガードレールで禁止されているアクションが不可能発見的ガードレール(Config)特定のイベントが発生したときにCloudTrailに記録される仕組みダッシュボードOUやアカウント、ガードレール違反などが一覧表示できるAWS Control TowerではできないことAWS Control Towerでは提供されてない機能もあります。GuardDutyやSecurity Hubなどのセキュリティ機能を組織全体適用するにはOrganizationsの機能を利用する必要があります。AWS Control Towerの注意点、制約事項いろいろ資料を見てみてこの辺注意が必要かなという点を書いていきます。注意点既存アカウントの Control Tower への受入処理時にエラーになった場合、スタックセット内で自動実行される作業の一部手作業が必要になる参考:トラブルシューティング - AWS Control Tower独自ガードレールの追加は可能だが、容易ではない。必須ガードレールを外せない参考:必須のガードレール - AWS Control Tower各種セキュリティー機能は自動で有効化されないため、Control Towerの範囲外のセキュリティ機能は Control Tower の機能の外で管理が必要になる範囲内の機能: Config, CloudTrail, SCP範囲外の機能: GuardDuty, Security Hub, IAM Access Analyzer, DetectiveControl Tower 未対応リージョンを使用している場合、Control Tower適用リージョンと適用外リージョンが混在して管理が煩雑になる大阪リージョン未対応なのでマルチリージョンを考えるときに注意Control Towerはマネージドサービスであるが追加機能によっては手動バージョンアップ が必要になるケースがある参考: ランディングゾーンを更新する - AWS Control Tower参考: 更新について - AWS Control Towerログアーカイブアカウントで独自のログバケットを作成可能だが、非推奨参考: ランディングゾーンのセットアップに関する管理上のヒントリージョンの使用を制限する SCP の併用に注意が必要参考: AWS Control Tower リソースの作成および変更に関するガイダンスIaC との境界の検討が必要アカウント発行に関してはControl Tower(Account Factory)で手動で行い、その後のアカウント設定はTerraformで行うなどAccount Factory for Terraformを利用することでAWSアカウント発行は可能参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニングどこまでTerraformで対応するかは別途検討が必要制限とクォータS３へのログの保存期間は、最大15年間保存可能(最近アップデートされた)Security OU の共有アカウントの E メールアドレスは変更可能だが、これらの変更を AWS Control Tower コンソールで確認するには、Landing Zone を更新する必要があるAWS Control Tower Landing zone の OU には、OU あたり5個のSCPの制限が適用される300超のアカウントを持つ既存の OU は、AWS Control Tower に登録することはできない300を超える場合はOUを分ける必要があるOUのネストは２段階まで、孫OUを持つことはできない参考: AWS Organizations における組織単位のベストプラクティスAWS Control Towerを使うべきなのかマルチアカウントを展開していくのであれば、AWSのベストプラクティスに乗れるので、使用するのが無難です。ただし、独自のLanding Zoneをすでに構築しており、Account Factoryの仕組みも独自で構築できているのであれば、移行コストを鑑みてそのままでも問題ないです。必須の予防的ガードレールが許容できない、OUなどの制限にひっかるなどの運用上の制約がある場合は使えないので、組織のポリシーを見直すか、独自でLanding Zoneを作るかを考える必要があります。発展もっと調査したかったが、時間が足りなかったことや今後調べたいことです。コンソールからAccount Factory実行するとService Catalogの設定項目がありますが、Service Catalog自体の理解不足でどう扱うのかが把握できてないのでこの辺調べたいです。Account Factory for Terraform(AFT)を使うとアカウント発行そのものもIaC化できるので試したい。参考: AWS Control Tower Account Factory for Terraform によるアカウントのプロビジョニング参考: ついにControl Towerのアカウント発行からカスタマイズまでIaC対応！Account Factory for Terraform (AFT)が新登場 #reinvent | DevelopersIOCustomization for Control Tower(CfCT)を使うとアカウント発行のイベントをトリガーにCloudFormationを実行できるので、これも実験したい。参考: AWS Control Tower のカスタマイズ (CfCT) の概要 - AWS Control Tower参考: Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIOまとめControl Towerについて調べたことを書いていきました。実運用自体はまだしてないので、これから触ってみて知見が溜まってきたらまたそれも共有できたらと思います。

AWS Control Towerを調べる

7年ぶりにふり返りするような気がします。これぶりですかね。blog.masasuzu.net10月は思い立って細かいことでも記録に残すようにし始めたのでサブブログの月間投稿数が増えてます。このまま続けたいところです。メインブログは相変わらず0なのでちゃんと書きたいところではあります。2022-10-01から1ヶ月間の記事一覧 - ふり返る暇なんて無いね仕事10月は端境期だったので、技術検証をメインでやってました。技術メインブログの方はどちらかというとパブリック向けに書いてます。ただ、この方針だと記事がゆるい記事が書きにくくなってきたので、サブブログを作った経緯があります。サブブログの技術記事は他の誰かのためではなく未来の自分が思い出すために書くをモットーに書いてます。なのでゆるく、細かい系のことも気軽に書いてます。分からないことは分からないと明示する。途中でも経過を残す。恥も残す。そんな感じです。以前とくらべてGoogle Cloud回りを10月はいじってた感じですね。build-in commandのmanが引けなくて困った - ふり返る暇なんて無いねt3系インスタンスのスペックについて - ふり返る暇なんて無いねGoogle Cloudの外部HTTP(S)ロードバランサと外部HTTP(S)ロードバランサ(従来型)の違いがわからなかった。 - ふり返る暇なんて無いね未解決: Google Cloud Storageの静的配信でnginxで言うところのtry_files的なことをしたかった。。。。 - ふり返る暇なんて無いねはてなブログのカテゴリごとのRSSフィード - ふり返る暇なんて無いねGitHub Actionsで save-state とset-output が廃止されるようです。 - ふり返る暇なんて無いね故障と障害の違いがわからずに困惑してた - ふり返る暇なんて無いね資格PCA取りました!11月にはPCA、KCNA、年内にCKA、CKADを取ることを目標に業務とは別に学習してます。なお、業務ではGoogle CloudもKubernetesも今のところ触る余地ないです。が、将来の投資として学習してます。近い未来で使うのが目に見えてるので。Google Cloud認定 Professional Cloud Architect合格してた - ふり返る暇なんて無いね11月末ターゲットで2個資格試験受けます - ふり返る暇なんて無いね旅土曜日の午前中に温泉入るのにはまってます。休日の早い時間に行動すると時間の有効活用ができるなとしみじみ感じてます。人生に疲れたので熱海で温泉入ってきた - ふり返る暇なんて無いね横須賀で温泉入ってきた - ふり返る暇なんて無いね江ノ島に行ってきて午前中だけで満足した - ふり返る暇なんて無いね生活寒くなりましたが、がんばります。今季初暖房使いました。 - ふり返る暇なんて無いね技術書を複数回読むということ - ふり返る暇なんて無いねワクチン4回目打った💉💉💉💉 - ふり返る暇なんて無いね11月に向けてといっても11月始まってますが。11月は資格の勉強もあるし、新しい固めのお仕事も始まるので、だいぶヘビーになる予感を感じてます。寒くなる季節なので体調には気を付けつつも、引き続き温泉につかり、ブログ書くのも続けて行きたいですね。

2022年10月のふりかえり、まとめ

kichijojipm.connpass.com久しぶりにLTしてきました。久しぶりに外で発表したいなと思いつつ、だいぶブランクあるのでちょうどいいリハビリできるところがないかな。— masasuzu (@masasuz) 2022年4月9日  こんなこと考えてたら良いタイミングできちぴーが開催されるので、LT申し込んでみました。#kichijojipm 7年ぶりにLTしたので緊張した。というのと、前回の発表調べて7年前もきちぴーあったのかという驚きもあった。— masasuzu (@masasuz) 2022年4月12日  どうやら7年ぶりだったみたいです。タイミング的に最終出社日の翌日だったので、キャリアの話をしました。diary.masasuzu.net正直、LTにおさまる量じゃなかったのは反省点です。資料ももうちょっとなんとかできたかなあという気持ちがあります。少しずつ登壇回数増やして、勘を取り戻していきたいところ。

吉祥寺.pm29で久しぶりにLTしてきました #kichijojipm

jawsug-sre.connpass.com聞いてきましたのでメモと感想を残しておきます。LTマネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjpマネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから中央集権構造サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった組織の規模に対してインフラチームがスケールしなくなった責務の分解点を再定義 DevOpsへ権限移譲フェーズ開発チームに権限を渡していくAWSとKubernatesを使用ランタイム、ミドルウェアも開発チームが管理サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つマイクロサービスごとにAWSアカウント管理して、リソースを管理するこれから権限は渡したが、運用まではむつかしい開発の運用を負荷を下げるためにTerraformのモジュール化、設定のバリデーションの整備AWSアカウントの統制、コスト可視化を進めたいアプリケーションランタイムのSnadbox化特殊要件なアプリケーションで使えるように開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。QAQ: 開発チームの権限移譲の苦労、運用面、技術面A: マルチアカウントをつかって 技術上の考慮点があった人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要ドキュメントとかで監視項目を揃えてあげるのに力を入れたQ: 開発とインフラでスキルセットの違いはあった?A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあったQ: EKSのテナント分割の単位A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが運用負荷を下げるためにマルチテナントを選んだSREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu内容に関しては、スライドに詳しく書いてあるので参照。SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' BlogQAQ: SRE主導でやるべきではなかったことA: SREは万能な人がおおくでできてしまう開発側のリソースが足りなくて急がないといけないことをSREがやってしまう本来はそうじゃないよねって話自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。Containerサービス と Toil と by スリーシェイク  @tt0603ECSとEKSについてToilと紐付けての話題。Toilの削減ステップ特定計測削減ただこのプロセスはつらい。SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。個人的にはEKSとECSのまとめがわかりやすくてよかった。QAQ: セルフホステッドを選択する場合は?A: 監視するとき Prometheus使うときとかつらいのでFargateは起動が遅い スケールが遅い技術選定において、自分たちの「サイズ」っていう要素が存在するというのは暗黙的なものになりがちなので、ちゃんと具体的に捉えておくの大事な気がした。 #jawsug_sre— Tomoya Kitaura (@kitta0108) 2022年2月25日  先程はパッと答えられませんでしたが、弊社の場合はMicroServiceを運用する際にはIstioを利用するケースが非常に多く、現状では対応していないため、EKSの場合はSelf Hostedを利用するケースが多いですー#jawsug_sre— TakuyaTezuka@3-shake (@tt0603) 2022年2月25日  パネルディスカッションMFのSREの組織のやり方で工夫してるところもともと中央集権的だった、開発に権限移譲していった権限を渡していっていながらそれ以上にプロダクトが開発が増えてしまったので負荷が増えてしまったenabling SREを広げる役割もつくるSREというポジションじゃなくてもSRE的な動きができるように組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' Blog技術支援からSREの組織変数がいくつか システムの規模 性質 組織規模、レベル感などpure sreではじめて権限移譲していく自分たちのサイズに合わせて組織を作っていく開発とSREのベストの距離感タイミングによって違う固定されたものじゃない構成をいかにシンプルにできるかが大事SREが開発に使いやすいサービスを提供するSREのAPIを提供するので好きに使って的な横断組織SREと開発チーム内SREというパターンもあるお互いのコミュニケーションは大事採用する際に求めるスキルセットやレベル感なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしいコミュニケーション 大事 ソフトスキルの担保が大事会社のバリューにあってるかSREワークブックの最後の方求められるスキル書いてあるすべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい変更時のトラブルシューティングはできるべきコードレビューできるスキルを持っていてほしいコーディングあるていどできる人組織による開発をSREに興味をもってもらうはどうしたらいいのだろうかSLOを決めて共通言語で話す留学すると面白いかもお互いがどういう観点で仕事してるかがわかってよいどこまで開発に移譲するかエラーバジェット、SLO、SLIは必要SREが設定するSLOより開発者が設定するSLOの方がいい開発者にとってうまいところを教えるアプローチ開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?あと、留学いいなあと思った。開発チームに留学したい。SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら兼務の限界値がある。得意なことにバリューを出せるようにしたい開発しながらAWSの新機能をキャッチアップするのはたいへんdevとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかもエラーバジェットが判断軸になるかもどれくらいのチームが困ってるかが判断軸になるToil撲滅の意味で費用対効果高かったLambdaランキング今Lambdaを殆ど使ってないchatbotが出たのでLambdaの役割を終えたEKS上にアプリケーションを作ってしまうことが多い必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる時刻でEC2終了するLambdaオートスケーリングでいいのでは?terrafromでLambda扱いにくい問題SREとしてセキュリティに対しての役割サービスInspectorECRのイメージスキャンCI/CD成立してからじゃないとイメージスキャンできないGuardDutySSOIAM Userを撲滅できたただ個別要件に対応しにくいSREが見てるケースが多いコーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇5,6人目にセキュリティが強い人がほしい着想の段階からセキュリティの観点をいれておきたいモニタリングロギングの観点で使用してるAWSのサービスAMPEKS使ってるのでコスパが良かったCloudWatch log通知考えるとLambda使わないとAthenaわずらわしい検索しにくいLokiとかに寄せたいログをどこにおくS3Lokiってこれかな?Grafana Loki | Grafana Labs雑感他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。

JAWS-UG SRE支部 #2 突撃！となりのSRE

future.connpass.com久しぶりにちゃんと勉強会の感想ブログ書きます。① State の分割戦略 〜ModulesとWorkspacesを利用して〜StateはTerraform上での管理を分ける意味では非常に重要な要素であり、適切に分けることで不慮の事故や予期せぬ変更からクラウドリソースを守ることができます。このセッションでは演者が実際にTerraformを利用して感じたことを交えながら、適切なStateの分割戦略とは？について話します。Stateの分割についてModuleによるアプローチとWorkspacesによるアプローチ、そしてそのあわせ技についての説明がありました。Workspacesは使ったことないのであまり知見がなかったので、いろいろ参考になる部分がありました。今のterraform運用だと環境ごとにディレクトリを切ってstateを分割してます。で、環境ごとの差異としてパラメータだけでなく、作るリソース作らないリソースが若干まちまちなので、そのままだとWorkspacesは向かないなと感じました。絶対に作るリソース、RDSやVPCなどは分割した上でWorkspacesで管理するのはありなのかなとは思いました。ただ、同じシステムで、環境毎のディレクトリとリソース毎のディレクトリが混在するのはわかりにくくならないかなという懸念はあります。悩ましいですねあと、ブランチ戦略も難しいですね。現状はmasterでprdをapplyするように、stagingでそれ以外の環境をapplyするようになってますが、全部masterでやるようにしても良いのではと思ったりもしてる今日このごろです。② クラウドリソース自体をdestroy/createdせずに、Terraformリソース定義の記述場所を変更する方法クラウドサービス上で稼働するリソースには一切手を付けずに、Terraformの定義記載場所だけを変更する方法を話します。Terraformを利用していると「このディレクトリ配置じゃダメだ。配置変えしたいのだけれど、リソースの再作成はできない。次にインフラ設計するときは、〇〇に注意しよう」という運用ナレッジが貯まると思います。スタート時点で完璧なTerraformディレクトリ設計ができれば御の字ですが、それが不可能なことは、この分野でベストプラクティスが確立されていないことにより証明されています。本パートでは「Terraformのディレクトリ配置には定石がないのだから、運用状況に合わせて柔軟に配置換えすべき」という観点から、「動作中リソースに影響なく、Terraform定義箇所を移植する方法」について話します。20220217_FutureTechNight_#20_TerraformState縛りの勉強会.pptx - Google スライドこんなふうに別のtfstateファイルにリソースをmvすることによって、Stateにリソースを移動できる手法を説明してました。terraform state mv -state-out=${moved_resource.tfstate} ${moved_resource}terraform state pull > ${to.tfstate}terraofm state mv -state=${moved_resource.tfstate} -state-out=${to.tfstate}terraform state push ${to.tfstate}State間でのリソース移動に関しては、terraform state rmとterraform importのあわせ技しか知らなかったので、新しい知見を得ました。まだ試せてないないんですが、State内での移動であれば、moved block使うのもありなのかなと思いました。ちなみリソースが消えた場合にもmove blockって使えるんですかね?なかなか他の会社のterraform運用の話を聞く機会があまりなかったので、楽しかったですね。最近勉強会出てもメモすら残さないことが多くて、せっかく参加したのにあまり有意義に時間を使えていなかったので、薄くてもいいので今後ちゃんと感想、意見を書き残していきたいと思いました。

Future Tech Night #20 Terraform State縛りの勉強会 #future_tech_night

株式会社モバイルファクトリーを3/31で退職してました。2010年6月入社なので9年10ヶ月になりますね。今は新しい会社のSREチームで働いています。前半数年間はケータイ向けのサイト(いわゆる着メロサイト)やソーシャルアプリの開発運用をしていました。後半数年間は社内全体の開発基盤・運用基盤の整備をしていました。いわゆるインフラよりのお仕事ですね。入社当時Webアプリケーション開発をまったく分かってなかったところからなんとか人並みに運用開発できる力をこの会社で身につけることが出来たと思います。今なんとかwebエンジニアをやれてるのはこの会社のおかげと言っても過言では無いと思っています。入社当時SQLをまともに書けなかったくらいのレベルだったのでよく採用されたなと。。。お仕事的には回りのレベルも高いし、自身の仕事のやり方も裁量を与えられていたし、社内環境も、待遇も悪くなかった。むしろ良かったくらいでした。ただ、長年勤めていく内に悪い意味での慣れが出てきて、自分自身停滞感を感じることが出てきました。ここ数年が特に感じることが多く、停滞感から来る焦りを日々感じていました。どうにか停滞感を解消するために副業として他社のお仕事を請け負ったりしていましたが、どうにも解消ができずにいました。そんな折に現職のSREチームの話をいただきました。実際に面談、面接を受けて、課題や環境の話を聞くにつれて、ここでなら一歩進めるのではないかという感触を得ました。もちろん焦燥感、停滞感はあれど、居心地が良いと感じてた今までの環境を変えることにはかなりの葛藤がありました。いろんな決め手はあったのですが、新しい場所の方が一番の下手*1でいれそう、なにより事業的にも業務的にも仲間的にもワクワクできそうというあたりが決定打になりました。入社して2週間しかも、初日以外ずっと在宅勤務なのでまだ様子が摑めてないですが、早くキャッチアップしてバリバリ成果を出していきたい所存です。これからもよろしくお願いします。例のもの置いておきます。気が向いたらでよいです。https://www.amazon.jp/hz/wishlist/ls/3S4C1LCDWKCTM?ref_=wl_share*1:情熱プログラマ参照

3月末日で退職してました

tech.mobilefactory.jpだいぶ前に受けたArchitecting on AWSの聴講記録です。

キャリアアップ支援制度を利用してArchitecting on AWSを受講しましたというアドベントカレンダー書いてました

tokyo.gdgjapan.org珍しく、何も予定が入ってない土曜日だったので、行ってきました。最近GCPを触る機運が出てきたのでちょうどいいタイミングでした。以下メモGCP 101 | 坂田 純 | GDG DevFest Tokyo 2019主にCloudRunの話。HTTPをlistenするコンテナを起動するサービス。使った分だけ課金対象となる。リクエスト数次第で自動的にスケールする。とお手軽にできそうな印象。インターフェースがHTTPなので基本的にはパブリックでアクセス出来てしまうが、--no-allow-unauthticatedオプションをつけてデプロイするとで限られた人だけ実行できるようになります。これでバッチ的なことができそう?マイクロサービスの開発とテストファースト/テスト駆動開発 | 柴田 芳樹 | GDG DevFest Tokyo 2019ちょいちょいブログとかは見てましたが、話を聞くのは初めてでした。還暦を迎えてもコードをバリバリ書いてるのは素直に尊敬します。メルペイのマイクロサービスのテストにも興味深かったですが、組み込みでのテストの話も興味深く聴かせてもらいました。ツールや環境の充実度の差はあれど、組み込みでもウェブでもやるべきことは同じなのだなと思いました。CloudNative 時代における GKE/Kubernetes ではじめる開発 | 青山 真也 | GDG DevFest Tokyo 2019k8sの紹介的な話。k8s好きになりました。話がすごいうまくて、めんどくさそうだなあと思ってたkubernetesの印象が変わりました。その他:D社のブースを覗いたらMOVの構成図が展示されていて、IoT関連だけAWSを使っていてそれ以外はGCPを使ってるのが興味深かった。IoT関連のものも別で実装して、AWSからは引き上げるようなことを言ってて、なるほどなあとなりました。基本的にAWSで構成されたインフラばかり見てたのでなかなか新鮮でした。

GDG DevFest Tokyo 2019に行ってきた

ちょっと過去の話ですが、会社の技術ブログで書いてました。tech.mobilefactory.jp

モバイルファクトリーのインフラアーキテクチャというアドベントカレンダー書いてました

この記事は、モバイルファクトリー Advent Calendar 2015 18日目の記事です昨日は@yashims85さんのAndroid drawableは画像を入れておくだけじゃないでした。今日は障碍の話です。普段障碍対応しているときにやってること考えてることをざっくりと時系列を追って書いていきたいと思います。コンテキストとしてはLinuxサーバでwebサービスをやっていると思っていただければと思います。障碍の検知webサービスを運営していれば、何かしらの監視システムからSlackなりIRCなりメールなり電話なりでアラートの通知が来ると思います。対応報告障碍対応をしている旨をメールなり、何かの連絡手段で伝えます。同じく見ている人がいれば調査作業の分担もできます。状況把握どこで障碍?アラートの通知内容にどのサーバで何が起きた的なことが書いてあるはずなので、それを確認します。だいたいの組織に於いてはサーバ管理表的なものがwebなりExcelなり設定ファイルなりにあるはずなので、そこと照らし合わせてどのプロジェクトのどのロールなのかを把握します。直前に何をした? いつもと違うことは何?webアプリケーションであれば直前に入れた変更が原因かもしれません。また、ちょっと前に入れていた変更だが、cronで時限発火したというケースも考えられるかも知れません。イベント開始で急にトラフィックが上がったと言うことも考えられるかも知れません。普段と変わったことは何かということが把握出来れば対処の幅が広がります。影響範囲は?サービス全体なのか、サービスの1機能の障碍なのか、ミドルウェア障碍なのか、影響がどの範囲に及んでいるのかを見ます。ミドルウェア障碍であれば、最近であれば、冗長化されてるのが普通なので、サービスから切り離して、監視から外せば終わりというパターンも多いです。サービス全体が落ちている場合は、ひとまず重要な関係者に状況の1次連絡すぐにした方が良いでしょう。接続出来る?そもそも、該当サーバに接続出来ない場合は、できることはほぼないので、該当サーバをサービスから外した上で、監視対象から外します。(単体のサーバ障碍の場合)# pingは通る?ping ${IP}# sshできる?ssh ${IP}ログの確認該当サーバ上で動いているミドルウェアやアプリケーションサーバのエラーログを主に見ます。だいたいこの辺に重要な情報が出力されている可能性があります。システムのログも確認した方が良いです。主にsyslogやkernelログを見ると良いでしょう。# syslogを見るless /var/log/syslog# kernelログを見るless /var/log/kern.log# kernelログを見る2dmesgサーバ状態の確認負荷の関係で障碍が起きているのであれば、現在のサーバの状態を確認しましょう。以下のようなコマンドが現状把握に役立つでしょう。# loadaverageおよびログイン中のユーザを見るw# 変なプロセス無いか見るps -ef# orps auxwwww# 開いているポートを確認するnetstat -tlnp# ネットワークコネクションを確認するnetstat -taopen# なにかCPU使いまくってないか見るtop# 現在の負荷の経過を見るdstat -tamsl 5# 過去の負荷情報を見る## CPUsar## memorysar -r## lasar -q対処直前のコミットにバグを入れ込んでしまったのであればリバートすれば解決するでしょうし、特定のサーバ落ちたのであれば、サービスから外してあげるだけで良いかも知れません。障碍の内容によって対処方法は様々です。ここで気を付けたいのは二次災害を起こさないことです。可能であれば、コマンドなり対処スクリプトのレビューをしてもらったり、現状認識に間違いがないかを周りの人にしてもらうと良いでしょう。(往々にして一人で障碍対応せざるを得ない場合もありますが。。)事後報告障碍対応が終わったら、記憶が新鮮なうちに下記の内容をまとめてしかるべき場所に投稿します。この辺の報告のフォーマットはだいたいの組織において決まっていることが多いでしょう。障碍内容影響範囲経過対処方法将来の対策面倒くさがらずに事実をなるべく詳細に書いておくと未来の自分や自組織のためになると思います。私の組織でも過去の障碍報告がだいぶ良い感じにデータベースになっており、たまに読み返すと気付きが得られます。また、この障碍報告を元に、同種の障碍をなるべく起こさない仕組み作りをしていくことが肝要だと思います。終わりに自分が障碍対応しているときにやってること、考えてることをざっくり書いてきました。誰にやり方を教わったわけでもないので、そこは違うとかこうした方がいいとかあれば、いただけると幸いです。明日は、@lycoris102さんのGameJam部 活動年間活動報告です。きっと面白い話なのではないでしょうか。

障碍対応と私

参加しました。雑なスライドですみません。スライド中に出てきてるやつはどれも五反田のお店で出てきます。五反田企業のガイアックスさんとかモバイルファクトリーさんはPerlの会社なので、美味しいごはんを食べたい人は検討してみてはいかがでしょうか。そういえば、Chiba.pmの開催回数がKichijoji.pm、Gotanda.pmに抜かされそうです。。

#chibapm Chiba.pm#7に参加しました。

この記事は、モバイルファクトリー Advent Calendar 2015 11日目の記事です※ 投稿内容は私個人の意見であり、所属企業・部門見解ならびに技術戦略を代表するものではありません。昨日は@rymizukiさんのnpmライブラリの運用と管理についてでした。今日はPerlの話です。お仕事やプライベートでPerlのwebアプリケーションを書くことが多く、いろいろ知見が溜まってきてるので、ここで少し紹介しようと思います。今回はPlack/PSGIなwebアプリケーションの実行環境の話です。mod_perlなアプリケーションとはちょっとコンテキストが違います。少しかっちりコンテキストに近いです。個人で軽くwebアプリケーション立てるならもう少しゆるふわでも問題ないはずです。OSUbuntuのLTSを使うことが多いです。Ubuntu前提の内容が後に続きます。PerlSystem Perlは使ってません。OS/ディストリビューションが変わってもなるべくそのまま動くようにしたいためです。perl-buildで独自ビルドしたPerlを使います。インストール場所としては、 /usr/local/perl/perl-5.${VERSION} に置きます。Perlを独自ビルドしたものをDebian package化して実行環境にはインストールします。他の方法としては、ビルド済みのperlをtarで固めて、配布するというのもあります。どちらでも構わないのですが、ローカルネットワークにaptサーバ立てている関係で、Debian packageの方が運用しやすいのです。また、perlのマイナーバージョンアップの際もDebian packageを作り直した上で、 apt-get upgrade (or aptitude safe-upgrade)で完結するので、aptの操作に慣れていて楽というのもあります。モジュール管理今風にcpanfileでモジュール管理してます。モジュールインストールはCartonを使ってます。Cartonの後継でCarmelも開発されてます。個人的にはそろそろ触っておきたいところです。また、cpanfile.snapshotもレポジトリに入れています。一般的なモジュールは特定の(古い)バージョンに依存せずに動くべきですが、依存モジュールのバージョン違いによって現在動いているアプリケーションが壊れるのを防ぐために、バージョン固定します。cpanfile.snapshotがある状態で下記のように carton install してあげると、どの環境でも同じバージョンのモジュールがインストールされます。carton install --deployment --without develop,test今やってないですが、別方法としては、モジュールがインストール済みの状態で、 carton bundle すると vendar/ にモジュールのtarが固められるので、それもレポジトリ管理した上で、下記の様にインストールするという手もあります。インストールの際は vendor/bin/carton  にfatpackされたcartonコマンドが入るのでそれを使います。(アプリ実行環境にcartonを敢えて入れる必要は無い)# 依存モジュールを固めるcarton bundle# インストール# env.shは後述./script/env.sh vendor/bin/carton install --cached --deployment --without develop,testさらに別方法としては、ビルドサーバで依存モジュールをビルドした上で、ディレクトリごと実行環境にrsyncしてあげる方法です。ビルドサーバを運用しているならば、この方法でも良いでしょう。参照Carton考2014carton bundle && carton install --cachedの使いどころ独自モジュールなるべく、独自モジュールは使わない方が良いのですが、個人的な事情などで、CPANに公開出来ないモジュールに関しては、OrePAN2 でDarkpanを作ってそこからローカルに配信するようにしてます。OrePAN2のサーバを簡単に立ち上げられるOrePAN2::Serverがありますが、一時期は使っていましたが、モジュールのアップロード機能は別にいらないなどの理由で今はwebサーバから静的配信してます。環境変数プロジェクトのレポジトリに config/env.rc という名前で、アプリケーションを動かすために必要な環境変数を定義したファイルを作ります。PERL5_VERSION="22"export PROJECT_BASE="/path/to/project"export PERL_CARTON_MIRROR="http://orepan.local/"export PERL5LIB="${PROJECT_BASE}/local/lib/perl5:${PROJECT_BASE}/lib"export PATH="${PROJECT_BASE}/local/bin:/usr/local/perl/perl-5.${PERL5_VERSION}/bin:${PATH}"export PLACK_PORT=5555また、 script/env.sh という名前で config/env.rc を読み込んだ上で、プログラムを実行するラッパースクリプトを作ります。スクリプトなどは基本的にこれを通して実行します。#!/bin/bash -ue# 諸々環境変数を設定した上でコマンドを実行する君##       env.sh perl hogehoge.pl#source /path/to/project/config/env.rcexec "$@"開発環境で、いちいちラッパースクリプト通すのが面倒な場合は、config/env.rc のsymlinkをプロジェクトルートに .envrc として張った上で、direnv使って済ましてしまう場合もあります。web サーバ起動スクリプトpsgiファイルを plackup するのではなく、こんな感じのスクリプトをscript/web みたいな名前で 用意してアプリケーションサーバを起動するようにしてます。#!/usr/bin/env perluse strict;use warnings;use lib "$ENV{PROJECT_BASE}/lib";use Plack::Loader;use SomeApplication::Config;use SomeApplication::Web::Handler;my $config = SomeApplication::Config->load();my $app    = SomeApplication::Web->to_app();Plack::Loader->load(    $config->{psgi}->{server},    %{ $config->{psgi}->{config} },)->run($app);また、このスクリプトをstart_serverを経由して起動することで、(graceful restartによる)ホットデプロイをできるようにしてます。start_server のプロセスにSIGHUPを送ると子プロセスのアプリケーションサーバを再起動してくれるのですが、 plackup コマンドで起動してると start_server に渡した引数をそのまま使ってplackup を再起動するので、 max_workers の数を変えたいときなど、 start_server 自体のプロセスを再起動しなくてはならないので不便です。なので、起動スクリプトを作ってます。そのほかにも理由があるのですが、参照リンクに詳しくあります。サーバ実装としては、StarletやGazelleを使ってます。参照PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ普通に使う Plack/PSGI ServerGraduate from .psgiデーモン管理現在はUpstartでアプリケーションサーバのデーモン管理してます。以下の理由で、個人的には好きでした(過去形)。最新のUbuntuはSystemdに変わってしまったので、将来的にはSystemdに移行することになるでしょう。Ubuntuに標準で入っていてサーバ起動時の自動起動してくれてデーモン異常終了時に自動再起動してくれて設定はわりかしわかりやすい/etc/init/web-some-application.conf みたいな名前でこんな設定ファイルを作りますdescription 'some web application'author 'masasuzu <hogehoge@masasuzu.net>'start on runlevel [2345]stop on starting rc RUNLEVEL=[016]setuid webappsetgid webapp# 異常時に再起動するrespawnscript    . /path/to/project/config/env.rc    export PLACK_ENV="production"    exec ${PROJECT_BASE}/local/bin/start_server \        --interval 10           \        --port ${PLACK_PORT}    \        -- ${PROJECT_BASE}/script/service/webend script上記のファイルを作ると以下のように操作出来ます。reloadでSIGHUPが送れるので、アプリケーションサーバのstart_server経由のgraceful restartができます。# 起動service web-some-application start# 停止service web-some-application stop# (start_serverのプロセスごと)再起動service web-some-application restart# Plackサーバを再起動service web-some-application reloadアプリケーションサーバ以外も、ジョブのワーカーなども、独自に設定ファイルを作って、Upstart経由で起動したりしてます。Upstart以外の選択肢としては、先に挙げたSystemdの他、以下のものがあるでしょう。好みと要件に合わせて使えば良いと思います。daemontoolsSuvpervisordSystemd参照Server::Starterから学ぶhot deployの仕組みServer::Starter の --interval オプションは大切Upstart を使ってお手軽 daemon 化Upstart Intro, Cookbook and Best PractisesおわりにWAF(Web Application Framework)やログの話など膨らまそうと思えばもっと膨らませられますが、実行環境の話なので、ここまでで抑えておきます。ざっくりと、Plack/PSGIなアプリケーションの実行環境について説明してきました。PerlでWebアプリケーションを作る時に何か参考になれば幸いです。また、もっと良い方法があれば、教えていただけるとありがたいです。明日は、@nekobato さんです webpackのなにか面白い話があるんじゃないかとわくどきしてます。

Plack/PSGIなwebアプリケーションの実行環境

この記事は、モバイルファクトリー Advent Calendar 2015 4日目の記事です今日は、Github APIの話です。Githubの管理作業は他のWebサービスと同じく基本Webコンソールでできます。ただ、Organizationとかを管理してる場合、ある程度以上規模が大きくなると、定型的な管理作業が増えて、Webでぽちぽちやるには煩雑でつらくなってきます。ここで怠惰エンジニア*1はどうにかこの定型作業を自動化/スクリプト化できないかなと考え始めます。幸い、GithubにはAPIがあるので、これを利用して要件に合わせて、実装することができます。ドキュメントは以下の場所にあるので、各APIの使い方などはそちらを参照してください。GitHub API v3 | GitHub Developer Guideapiアクセスを投げるpublicな情報を取得するには普通にcurlでGET発行するだけで、取得出来ます。curl https://api.github.com/users/masasuzu/reposが、これだけでは、privateな情報にアクセスできません。ので、Basic認証をしてアクセスをします。curl -u ${USER}:${PASSWORD} https://api.github.com/orgs/some_privete/reposただ、この場合、このアカウントで出来ることが全て実行出来てしまうので、下記のリンクからアクセストークンを発行して、権限を絞ってAPIにアクセスするのが望ましいです。アクセストークンは作成時にしか見れないので、ちゃんと書き留めておくようにしましょう。Personal access tokensアクセストークンを使用した場合、下記の3つの方法で認証出来ます。curl -u :${ACCESS_TOKEN} https://api.github.com/orgs/some_privete/reposcurl -H 'Authorization: token ${ACCESS_TOKEN}' https://api.github.com/orgs/some_privete/reposcurl 'https://api.github.com/orgs/some_private/repos?access_token=${ACCESS_TOKEN}'ドキュメントに各API発行に必要なscope(権限)が書いてあるので必要なscopeだけ付与してあげると良いです。perlでの選択肢今までで、APIアクセスする手段を得ることはできましたが、シェルスクリプトで処理を組み立てるのは、無謀なので、使い慣れてるプログラミング言語で実装したいところです。当社ではPerlを使い慣れてるエンジニアが多いので、ここではPerlのクライアントを紹介します。現在のところ以下の2つの選択肢があります。PithubNet::Github私はPithubを使っています。使い始めた時期においてPithubの方が更新されてそうだったからです。が、今見るとNet::Githubも更新されてるように見えます。他の言語での選択肢特にプログラミング言語にこだわりが無いのであれば、githubがメンテナンスしてるoctokitを使うと良いと思います。RubyとObjective C、.Netに対応してます。たぶん鉄板だと思います。(しかし、octokitのこのサンライズというかバンダイに怒られそうなデザインは大丈夫なのでしょうか?まとめ煩雑で定型的な作業はGithub APIで自動化すると良いPrivateな情報の操作はアクセストークンを発行してAPIを発行するPerlにはPithubとNet::Githubのクライアントライブラリがあるこだわりがなければ、クライアントはoctokit使うと良い明日は、 @mihyaeru21 さんです。iOS回りの面白いエントリが見れそうです。*1:プログラマの3大美徳の1つ

Github APIを使おう

gotanda-pm.connpass.comGotanda.pmでLTしてきました。今回のテーマは障碍でした。半分ネタのトークです。JSTQB Foundation Level のシラバスに載っているソフトウェアテストの7原則をもじったやつです。JSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-言ってみれば、サービスに対して継続的にテストするのが監視なのでテストに対する原則が監視に対しても言えるんじゃないかなーという軽い思いつきから生まれました。無理矢理な部分もありましたが、わりかし当てはまってる部分もあったのではないかと思いました。トーク中美味しいにおいがしてきてつらかったです。(このエントリは懇親会の前に書かれてます)#gotandapm 美味しそうなにおいがして辛い。。。。— masasuzu? (@masasuz) September 17, 2015ガイアックスさん会場提供ありがとうございました。

#gotandapm Gotanda.pm Perl Technology Conference #6 でLTしてきました。

今年のYAPC::Asiaは終わった。つつがなく終わりました。過去のエントリを見直すと2011、2012年は書くのサボっていたみたいでした。私のYAPC::Asia初参加は2010年で6回目の参加でした。#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前に僕らの道があるmasasuzu.hatenablog.jp#yapcasia YAPC::Asia Tokyo 2013に参加してきました。 - 目の前に僕らの道があるmasasuzu.hatenablog.jpYAPC::Asia 2010へ行ってきたよ。 - 目の前に僕らの道があるmasasuzu.hatenablog.jp今年のYAPCとの関わり方は個人スポンサー+ボランティアスタッフとして参加しました。個人スポンサーとしては4年目、ボランティアスタッフとしては3年目でした。今年のYAPCもすごい楽しかったです。特にここ1,2年でPerl関係の人たちの知り合いがすごい増えたので、いろんな人と話ができてすごい楽しかったです。トークの方は例年スタッフ業をやっていると聞けないので、(会場にいてもスタッフのお仕事に意識が行くので内容を聞き取れてないことが多い)、動画が上がったら気になっていたトークを追いたいと思います。さて、だいたい6年前からWebで、Perlでお仕事するようになってからYAPCにはいろいろなものをもらってきました。だからこそ、ボランティアスタッフをやったり、個人スポンサーになって自分がもらったものを間接的に他の人に与えられたらいいなと思ってやってきました。自分がもらったものを他の人も受け取ってもらえたらなら良いなと思います。YAPC::Asiaはいったん終わります。それ自体いろいろ思うところがありますし、残念ではあります。YAPC::Asiaが無くなっても地域PMなどのPerlのコミュニティ自体が無くなるわけではないので私も細々とコミュニティ活動していきます。ただ、全国的にPerlな人が集まってくるイベントが今のところ来年無いのは寂しいところです。もしどこかで動きがあるならお手伝いさせていただければなと思います。YAPC::Asiaお疲れ様でした。(初日の懇親会の後の二次会でいろんな人に迷惑かけてしまったようなのでものすごく反省しています。すみません。お酒気を付けます。。。会期中のつぶやきいくつかおしゃれなカップだ #yapcasia pic.twitter.com/NwWw30i3HW— masasuzu? (@masasuz) August 22, 2015#yapcasia Perl6！ pic.twitter.com/2tJh6irctZ— masasuzu? (@masasuz) August 22, 2015#yapcasia  壇上から。お疲れさまでした！！ pic.twitter.com/1MiU56gE4R— masasuzu? (@masasuz) August 22, 2015

#yapcasia YAPC::Asia 2015でボランティアスタッフしてきた

吉祥寺.pm (kichijojipm) #4 : ATNDatnd.org今回はPerlとPerl以外ということで、Perlの外の世界をつないでるもので一番最初に思いついたのがテンプレートエンジンだったので今回の発表になりました。自分のテンプレートの利用シーンは設定ファイルの自動生成ですね。テンプレートがあることで手作業で設定ファイルをいじる必要が基本的にはないので、手作業に起因ミスがないのが良いですよね。そのほかくりかえしの記述が必要なものもテンプレート使うと便利な場面が多いと思います。前回のLTが長すぎたので、真姫進行で行ったら、巻きすぎてしまいました。時間配分難しい。#kichijojipm 真姫すぎた。。— masasuzu? (@masasuz) July 10, 2015#kichijojipm 巻きすぎた。。— masasuzu? (@masasuz) July 10, 2015懇親会のお店はおしゃれな感じでさすが吉祥寺という感じでした。五反田とは違う。#kichijojipm 炙りマカレル pic.twitter.com/wpJTTnIvZF— masasuzu? (@masasuz) July 10, 2015他の人のスライドはこちらページからたどれると思います。吉祥寺.pm4終わりました - kichijojipm’s blogkichijojipm.hatenablog.com今回の吉祥寺.pmも楽しかったです。次回も参加したいです。余談1今回のKeynoteはAzusa Colorsを元にスライドを作りました。だいぶ良い感じにできました。ありがたいです。茜屋さんのイメージカラーのパープルを基調にしています。http://memo.sanographix.net/post/113681262780memo.sanographix.net余談2LTの途中で宣伝してましたが、五反田のモバイルファクトリーさんで7/31にCrystalの勉強会やるしいですよ。東京 Crystal 勉強会 #1 in 五反田 (2015/07/31 19:30〜)crystal.connpass.comGotandaは今技術的に熱い街です。そのほかGotanda.pmや五反田Perlみたいな勉強会も様々行われてます。

#kichijojipm 吉祥寺.pmでLTしてきた

7月にとうとうなりました。ざっくりふり返ります。お仕事mod_perl to PSGI/Plackこの四半期のメインタスクでした。弊社2事業部あるんですが、そのうちの片方の事業部のmod_perlアプリをPSGI/Plack化しました。後は事業部の人がちゃんとテストして、本番反映するだけです。もう一個の事業部のmod_perlアプリケーションは次の四半期に取りかかる予定です。雑感としては、mod_perl特有の機能はほぼ使ってないので、そんなに辛くは無かったです。どちらかというと、使っているモジュールが古すぎたり、SledgeのPlugin地獄だったりしてアプリの実装の方でちょこちょこはまることが多かったです。このあたりの話です。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前に僕らの道があるmasasuzu.hatenablog.jpGitbucket地味にアップデートが出る度に追従してました。しかしながら、そこそこでかいレポジトリをGitbucketで管理するのはだいぶつらいことが見えてきました。まず、レポジトリブラウザが鬼のように重い。1日数10コミットするようなレポジトリだとまともに使えないので、ちょっと移行先を考えてます。Elasticsearch  + Kibana4Kibana4入れました。Kibana3もまだ稼働中ですが、Kibana4で十分かなという気分です。Kibana4はすごい便利なので、そのあたりの話もどこかで一度したいです。開発環境の改善OrePAN2::Serverを廃止して、社内モジュールは静的サーバ置いたり、一つサーバでマルチユーザが同居するようなレガシーな開発環境の改善とかもろもろやってました。この辺もあとでエントリ書きたいところ。新卒技術者のメンタリング新卒技術者に対して仕事外で困ってる事とかのお悩みの相談乗ったり、成長を促すお手伝いをしたいたりします。会社としてもメンター制度できたばっかりで、組織的にも自分的にもいろいろ手探り感があるのは確かです。自分が見ている人はかなり優秀で日々成長が見て取れるので、そこをさらに促せるようにしていけたらと思います。書いた記事こう見るとあまりエントリ残してないですね。もう少し書きたいところ。4月勉強会#kichijojipm 吉祥寺.pm #3 に参加してきました。 - 目の前に僕らの道がある技術ubuntu12.04でruby2.2.1のビルド失敗するのはlibffi-devが入ってないから - ふり返る暇なんて無いね$PATHを見やすく表示したい - ふり返る暇なんて無いね5月技術ポートが空いてるか調べたいとき - ふり返る暇なんて無いねサーバ起動時に/etc/init.d/ に設定があるデーモンを自動起動したい - ふり返る暇なんて無いねElasticsearchを1.4以上に上げたらkibana3がElasticsearchにConnection Failedする際の対処 - ふり返る暇なんて無いねポエム縮退運用という考え方 - ふり返る暇なんて無いねあなたは嫌いですか。でも僕は好きです。 - ふり返る暇なんて無いね6月勉強会#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました - 目の前に僕らの道がある技術MySQLのLINEAR KEY パーティションでPKで検索しても遅い場合 - ふり返る暇なんて無いねPerlモジュールのバージョン比較したい - ふり返る暇なんて無いねポエム普段の行動がものをいう - ふり返る暇なんて無いね判断と判断の変更 - ふり返る暇なんて無いね感覚値はあくまで感覚値 - ふり返る暇なんて無いね次の四半期お仕事的にはもう一個の事業部のPSGI/Plack化と開発環境の改善をメインにやってくと思います。ここ最近ちょっといろいろ腹に貯めすぎなので、もう少し心にゆとりをもっていけたらなとは思いまする。

2015年第二 四半期をふりかえる

エンジニア交流会〜他社の障害対応きにならNight!〜 on Zusaarwww.zusaar.com一昨日の話ですが、Gaiaxさんに行ってきました。内容に関してはけっこうグレーな感じなこともあるので、話せないのですが、あー、あるよねー。とか だいぶつらい。。。って話を聞けて楽しかったです。他山の石にしたいです。インシデント管理に関してはちょっと痛いところがあるので見直したいなと思いました。懇親会で深い話が聞けていろいろ学びがありました。すごい楽しかったので次回もあれば参加したいです。寿司 pic.twitter.com/RnLrH5mxlp— masasuzu? (@masasuz) June 30, 2015内容言えないけどすごい為になってる— masasuzu? (@masasuz) June 30, 2015だいぶつらい話聞いてるもの— masasuzu? (@masasuz) June 30, 2015炎上案件だ。。。— masasuzu? (@masasuz) June 30, 2015インシデント管理に関してはちょっと痛いところあるなと思った。— masasuzu? (@masasuz) June 30, 2015なかなかこういう他社の障害事例聞けないので、今日は楽しかった。— masasuzu? (@masasuz) June 30, 2015innodbのデータ圧縮すると並列性が犠牲になるってのは、初耳だったのでちゃんと調べたい。— masasuzu? (@masasuz) June 30, 2015

他社の障害対応きにならNight! に行ってきた

Gotanda.pm Perl Technology Conference #5 (2015/06/24 19:30〜)gotanda-pm.connpass.comGtanda.pmでLTしてきました。#gotandapm LTの高速化に失敗しました。— masasuzu? (@masasuz) June 24, 2015内容としてはPlack Applicationのアクセスログの話です。アクセスログそのものの話アクセスログの収集の話アクセスログの可視化/集計の話1個目の論点しか話せませんでした。猛省します。次回は事故らずに話したいです。最近Kibana4とElasticsearchを使っていてだいぶアクセスログに限らず ログ解析が捗っているので、その辺も別の機会に話せたらと思います。他の人の発表では、skajiさんの Acme::CPAN::Installerの発表がすごかったです。cpanモジュールをインストール出来るとこんなに速くなるのかと感心しました。業務で使いたいと思うくらいには速かったです。そのほかの人の発表も楽しく聞かせてもらいました。gotandapm参加者の皆さん！吉祥寺.pm4は、まだまだ参加者募集中です！https://t.co/JwGFxDOnXi#kichijojipm #gotandapm— magnoliak (@magnolia_k_) June 24, 2015どうやら吉祥寺.pm 来月開催らしいですよ。

#gotandapm Gotanda.pm Perl Technology Conference #5 でLTの高速化に失敗しました

吉祥寺.pm行ってきました。吉祥寺.pm (kichijojipm) #3 : ATNDatnd.org今回はツールチェインがテーマと言うことで、Minillaの話題が2件ほどあって、参考になりました。今回特によかったなと思ったのがpapixさんの新人研修の話でした。ガイアックスさんはここ二年くらいで新人研修を整備し始めたそうで、だいぶ充実した内容をやっていそうなので、こっそり参加したいです。#kichijojipm ガイアックスに新人研修受けに行きたい— masasuzu? (@masasuz) April 17, 2015話の中で研修資料をスライドじゃ無くてドキュメントとして残すってのが、印象に残ってます。OJTが基本なのですが、開発グループのエンジニアの有志が社内勉強会枠の時間*1で新人さんに最低限知っておいて欲しい技術基礎の勉強会を行っています。wikiに残しておいて、次年度使い回せるように + 中途の人が入ってきたときも一通り見れば分かるようにしてます。その辺、アプローチが似ているなと思います。さておき、今回も楽しかったです、上級者向けの話からperl少し書ける人でも役に立つ話まで聞けてレベル感的にも良い感じです。主催のmagnoliakさん、htk291さんありがとうございました。次回の吉祥寺.pm楽しみにしてます。吉祥寺.pm in 五反田楽しみにしてます!!!五反田で吉祥寺.pmとか。— 吉祥寺.pm (@kichijojipm) April 17, 2015参照吉祥寺.pm3終わりました - kichijojipm’s blogkichijojipm.hatenablog.com余談SSID: TMNetwork がいてふいた— masasuzu? (@masasuz) April 17, 2015*1:弊社、毎日終業定時前の1時間は勉強会の時間と会議室が確保されていて、好きにやって良いことになってる。もちろん毎日は開かれない

#kichijojipm 吉祥寺.pm #3 に参加してきました。

そろそろ3月も終わりそうなので、軽くまとめてみる。お仕事Slack連携ツール昨年末から1月にかけては、社内のチャットツールをIRCからSlackに移すためにもろもろの連携ツールを書いていました。WevService::Slack::IncomingWebHookはそういう事情で書いたコードです。WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるmasasuzu.hatenablog.jp連携ツール自体は、Irisというプロジェクトコードで、HTTPでSlackへIncoming webhookを投げたり、SlackからOutgoing webhookを受けたりするProxy的なものです。コードは公開してないです。mod_perl to PSGI/Plack2月3月はmod_perlなプロジェクトをPSGI/Plack+Carton化をひたすらしていた感じです。このタスク自体は半期で終わらす予定なので、次の四半期も継続案件です。前回のGotanda.pmで話した件ですね。#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道があるmasasuzu.hatenablog.jp書いた記事1月H2データベースの話はGitbucketのDBの調子が悪くていったんデータをダンプしてDBファイルを作り直さなきゃいけなかった時の話のハズ。2014年に使った技術 - 目の前には僕らの道があるsudo -Hと環境変数($PATH)ではまった話 - ふり返る暇なんて無いねH2データベースのダンプ、リストアをする - ふり返る暇なんて無いね#chibapm Chiba.pm #6 に参加してきた - 目の前には僕らの道がある2月tmuxでwindow番号を変更したい - ふり返る暇なんて無いねperl5.16から overloadが"overload arg '"' is invalid "みたいなwarningを吐き出した - ふり返る暇なんて無いね情報共有に関してもやもや思ってること - ふり返る暇なんて無いね3月3月はちょっと古めのコードをいろいろいじっててはまっていたらしいですね。Perl 5.18からsmart matchはexperimentalなので使わないで - ふり返る暇なんて無いねとあるプロジェクトのコードのあんちぱたーん - ふり返る暇なんて無いねDebian Packageのバージョンを比較したい。 - ふり返る暇なんて無いね開発二部でLTしてきた #でぶつー - 目の前には僕らの道があるFurl::S3でSSL接続エラーが出る件 - ふり返る暇なんて無いね#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話 - 目の前には僕らの道がある設定と処理をわけるということ - ふり返る暇なんて無いねUbuntu 12.04で/tmpがおかしくてうまく起動しなかった件 - ふり返る暇なんて無いね次の四半期お仕事的には引き続きmod_perlを無くしていく作業を続けていると思います。お仕事外で現状これといってやりたいことはないんですが、最近仕事外のコードをあまり書いてないので、その辺少し改善できたらなとは思いまする。

2015年第一四半期をふりかえる

Gotanda.pm Perl Technology Conference #4 (2015/03/25 19:30〜)gotanda-pm.connpass.comだいぶ昔のmod_perlで動いているプロジェクトをPSGI/Plack化するために現在進行形で作業してるよという話です。直前に書き上げてリハーサル全くしないまま本番で話したので、全然時間が足りなかったです。#gotandapm つらいしか言わずに終わってしまった— masasuzu? (@masasuz) March 25, 2015さて、古いmod_perlなプロジェクトも新しめのプロジェクトと同じスキームに載せて動くように現在進行形で動いているところです。それはそれとして大人のGotanda.pmも面白そうですね。とはいえ、ソンナニ闇ハカカエテナイデスヨ。全然。大人のGotanda.pmとかやって, GXやMFのインフラ部署の人に闇語ってもらいたい #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015ちなみに、新しめのプロジェクトで使っているスキームはそういえば、Gotanda.pm #1で話したくらいに作っていたようです。#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道があるmasasuzu.hatenablog.jp会場をお貸しいただいたGaiaxさんありがとうございました。運営のみなさんもお疲れ様でした。ありがとうございました。Gotanda.pmお疲れ様でした. 会場やUstreamは如何でしたでしょうか. 今回のように, 弊社セミナールームは勉強会会場として貸し出す事も出来ますので, 使ってみたいという方は @__papix__ までご連絡下さい. #gotandapm— パブリシティ権放棄型 (@__papix__) March 25, 2015蛇足ですが、Gaiaxさんのすぐ近くの麺彩房の油そば好きです。五反田ぴーえむ pic.twitter.com/6UBO7Y6fDi— masasuzu? (@masasuz) March 25, 2015

#gotandapm Gotanda.pm Perl Technology Conference #4 話してきた話

開発二部という社内の部活でLTをしてきました。最近古めのプロジェクトを多少モダンにするタスクをしてるので、そのあたりで得た知見を書いてます。特に何かを批判したいわけではなく、こういうのはよくないから、新しいプロジェクトではこういうことは避けると幸せになりやすいよと言いたいだけです。よくないコードは直すだけです。ただdisって何もしないのはよくないですし、そういうことをしたいわけではないです。

開発二部でLTしてきた #でぶつー

行ってきました。Chiba.pm #6 : ATNDChiba.pm #6 : ATNDCPAN Authorになったのでその辺の話をLTしてきました。前にエントリを書いた話です。Minilla便利でした。Chiba.pmなのにPerlの話をしてすみませんでした。。。。久しぶりのChiba.pm楽しかったです。マグロ美味しかったです。次回も楽しみです。過去のchiba.pm#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるchiba.pm 2回目に行ってきた #chibapm - 目の前には僕らの道がある#chibapm #1に行ってきた。 - 目の前には僕らの道がある

#chibapm Chiba.pm #6 に参加してきた

ざっくりと去年使った技術をざっくりふりかえってみる。ホントにざっくりです。PSGI/Plack今働いている会社のwebサービスのバックエンドはperlで動いています。そしてそれらのアプリケーションはmod_perl上で動くようになっていました。*1があってそろそろmod_perl卒業したいよねと検証自体は重ねていたんですが、年初くらいに都合よくほかのサービスに影響を与えることのない小規模な新規プロジェクト*2を作ることになりました。もの自体は1週間くらいでくみ上げました。ここで組んだベースアーキテクチャが以降のPSGI/Plackのプロジェクトのベースになっています。Perl::Build / xbuildtagomoris/xbuild · GitHubPerl::Build - perl builder - metacpan.orgperlに依存するとディストリビューションやOSを変える度にperlのバージョンが変わっていろいろ面倒なので、PSGI/Plack化したプロジェクトではperlを独自にビルドするようにしてます。perl-buildでビルドしたperlをdebian package化して使っています。各サーバでperlをビルドするのは時間の無駄遣いなのでdebで配布します。CartonCarton - Perl module dependency manager (aka Bundler for Perl) - metacpan.orgsystem perlを使っていたときは、perl moduleもdebian packageで入れていたんですが、独自ビルドするようになったので、モジュール管理にcartonを使ってます。OrePAN2::ServerOrePAN2::Server - DarkPAN Server - metacpan.org基本社内モジュールは作らない/作らせない/CPANに上げやがれという方針ですが、どうしても外には出せない社内ロジックがあるのでそういうものを置く場所として使っています。UpstartUbuntuで動いているサービスのデーモン管理はupstartに基本任せています。設定ファイル書くの簡単で、癖がそんなにないので重宝しているんですが、なんか次のUbuntuからsystemdに移行するみたいな話があってだいぶ辛い予感がしてます。FluentdFluentdを全サーバに導入しました。今まで各サーバに入ってgrep/wc/sed/tailを駆使してログ解析していたアプリケーションログ(イベントログ)、アクセスログ、エラーログを1つの場所に集約できるようになってだいぶ捗ってます。アクセスログに関しては最終的にvhost毎と vhostとstatus code(4xx,5xxxのみ)毎にファイルを分けて出力するようにしてるので、アクセスログ解析が今までよりだいぶ捗るようになりました。だいぶライフチェンジングです。Elasticsearch / KibanaFluentd入れた時点でだいぶログ回りは快適になったんですが、それでも最終的なログのストア先はファイル*3なのでアプリから扱うには少し不便とか諸事情あったので、いろいろ検証した上でElasticsearchを入れました。GitBuckettakezoe/gitbucket · GitHubgitレポジトリへのアクセスは基本sshを使っていたんですが、開発者以外の企画者やデザイナもgitを使うようになってきて、いろいろアカウント管理の問題が出てきて素のままgit使うのはちょっと管理上つらいというのがきっかけでその辺解消するために導入したのがgithub cloneのGitBucketでした。レポジトリブラウザとしてよいのですが、歴史が深いレポジトリとかだとだいぶ重かったりするのが少し難点です。Slack試験導入中です。正直別にIRCでもよくね?感がまだあります。デフォルトでwebから見れるという点は便利なような気がしなくもないです。なんかほかにもやったような気がしますが、去年はざっくりこんなことしていたらしいです。*1:system perlにはもう依存したくないよねとかいろいろ。察してください*2:ちなみにStartDash(START:DASH!!)というプロジェクトコードを付けていた。察してください*3:一定ファイル容量でローテートされる。そしてgzip圧縮してるのとしてないの(バッファ)が混じってる

2014年に使った技術

書いたエントリのリンクを貼り付けるだけの雑なふりかえりです。一応自分の技術ブログが2つあって、ここが勉強会のエントリや、わりかしまとまった技術に関して書くところ。もうひとつ(ふり返る暇なんて無いね)の方がゆるふわにメモやポエムを書いていく方。1月PERL_CARTON_MIRRORをOrePAN2::Serverに向けてcarton installすると怒られる - ふり返る暇なんて無いね2月この時期なにやっていたっけ?全く記憶に無い3月hostnameコマンドメモ - ふり返る暇なんて無いねfluent-plugin-forestを使いつつ、tag_partsが複数あるときにpathにtag_partsを含めたときに、same buffer_pathを使っていると怒られる。 - ふり返る暇なんて無いねエンジニアでもターミナル作業ログを残したい!! - 目の前には僕らの道がある4月プロセスが開いているファイルディスクリプタ数を知りたい - ふり返る暇なんて無いねプロセスがオープン可能なファイルディスクリプタを知りたい - ふり返る暇なんて無いねUbuntu12.04のapproxはinetd経由で立ち上がる件 - ふり返る暇なんて無いねLINE Developer Conference(テーマ：インフラ)にいってきたメモ - 目の前には僕らの道がある5月carton installするたびにcpanfile.snapshotが更新されるのがうざったい - ふり返る暇なんて無いね6月キャッシュ(しない)戦略 - ふり返る暇なんて無いね溜まるジョブキュー - ふり返る暇なんて無いねinnodb_log_file_sizeを気軽に変えると死ぬよ - ふり返る暇なんて無いね監視の閾値の考え方1 - ふり返る暇なんて無いねこのあたりはポエムを書きたいお年頃だったようだ。#五反田Perl でもくもくしてきた。perlのコードはほとんど書いてない。 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #1に参加した LTした - 目の前には僕らの道がある五反田が熱くなり始めたのもこの頃。7月コマンドの出力結果の一時ファイルを作りたくなったら、プロセス置換を思い出すと良いかも知れない - ふり返る暇なんて無いね8月#でぶつー 五反田もくもく会 #1 に行ってきた - 目の前には僕らの道があるマニュアルオペレーションするとき気を付けたいこといくつか - ふり返る暇なんて無いね-で始まるファイルを消す方法 - ふり返る暇なんて無いねUbuntu 12.04でGitBucketを使うメモ - ふり返る暇なんて無いね#yapcasia YAPC::Asia前夜祭でインスピレーションを得てきた - ふり返る暇なんて無いね8月末はYAPC Asiaでした。今年もスタッフやってました。9月#yapcasia YAPC::Asia 2014でボランティアスタッフやってきました - 目の前には僕らの道がある#gotandago Gotanda.go #1 行ってきた - 目の前には僕らの道があるエイリアスを使わないでコマンド実行するいくつかの方法 - 目の前には僕らの道がある#gotandapm Gotanda.pm Perl Technology Conference #2 に行ってきた - 目の前には僕らの道があるgolangに興味を持ち始めたのはこの頃、来年こそはちゃんと使えるようにしたい。10月boot2dockerでexposeされるportはlocalhostのportじゃないよ - ふり返る暇なんて無いね#chibapm Chiba.pm #5 でログ回りのことを聞きたかった - 目の前には僕らの道があるこの時期、Elasticsearchまわりでいろいろはまってたはずなのに一切アウトプットが無いな。。。。11月不思議な時間にlogrotateしているその理由は。 - ふり返る暇なんて無いねconnectがhomebrewで入らなくなったので自前でビルドする - ふり返る暇なんて無いね#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話 - 目の前には僕らの道がある#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話 - 目の前には僕らの道がある12月WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです - 目の前には僕らの道があるねんがんのCPAN Authorになったぞ!こう見てみると、今年もアウトプット量が足りないなという印象。実際業務でいろいろはまっていたはずなのに、そのことがまったく書かれてないので、もう少しメモ書きレベルでもいいので残していきたい。というのが来年の課題。ソースコードでのアウトプットももっとがんばらないと。良いお年をー。

2014年の自分が書いた技術エントリふりかえり

WebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgWebService-Slack-IncomingWebHook-0.01 - slack incoming webhook client - metacpan.orgはい。Web Hookを使ってSlackに投稿をポストしてくれる君です。post-slackというコマンドを同梱していてコマンドラインからも使えるようになってます。当初Net::Slackという名前を使っていたんですが、どうやらNetという名前空間はネットワークプロトコルを喋るモジュールが使うところで、webサービスのAPIを叩くようなものはWWWかWebServiceを使うらしいので、避けました。また、Slack APIが別にあるので、Slack単体名だとSlack API叩くように誤解されるのでさらに一段名前空間を斬ってます。スクレイピングしてる系という印象[要出典]があったので。WWWは避けた。参考: PAUSE: pause_namingmodules Netの項目そんな感じで CPAN おーさーとやらになったようです。CPANにあったので自分でモジュールを書く機会がなかなかなかったのですが、都合よく必要となってかつ誰も書いてなさそうという機会に今回恵まれました。Acmeモジュールはいくつか書いていたけど、それでCPAN Authorになるのはちょっと厭だと思って居た。初uploadなので粗があったらツッコミがあると幸いです。

WebService::Slack::IncomingWebHookというモジュールを書いてCPAN Authorとやらになったようです

吉祥寺.pm (kichijojipm) #1 : ATND吉祥寺とは縁もゆかりもないのですが、pmが近めの場所でやっているということで、お邪魔してきました。懇親会は結局2次会、3次会まで行ってオールになってしましました。perlの事情をいろいろ聞けて楽しかったです。吉祥寺良いところでしたので、次回あれば参加したいです。

#kichijojipm 吉祥寺.pm #1 に行ってきました (だいぶ昔の話

perlcasual #06行ってきました。PerlCasual #06 : ATNDだいぶ昔の話です。hogecasualと名のつく勉強会はだいたいカジュアルじゃ無いんですが(感覚値)、今回はだいぶカジュアルな感じだったと思います。perlのコマンドラインtipsがとてもよかったです。基礎的な部分でも意外にに知らない部分が多くて勉強なりました。懇親会ではperlの会話をあまりしてなかった気がしました。カジュアルですね。さて、カジュアル。perlをばりばりやっている人にとってカジュアルなのか。perl初心者にとってカジュアルなのか。他言語の人に対してカジュアルなのか。いろいろあると思います。その辺のターゲットは主催者のさじ加減だと思います。ところで、pelrcasualはperlをカジュアルに楽しむ初心者向け となってます。ただ、内容としてはカジュアルだとは思いますが、本当の初心者にはついてこれるのかなという感じはしました。本当に本当の初心者はperl入学式が引受先なのかなという感じがします。なんとなくカジュアルの意味するところは(初)中級者くらいのレベル感なのかなと。そう考えると(Perl Beginnersは参加したことが無いので本当のレベル感が分からないのですが)、Perl初学者が以下のようにステップアップしていけるとperlの裾野が広がっていっていいのかなーとか思いました。主催者はそんな意図では無いかもですが。Perl入学式 => (Perl Beginners) => PerlCasualって、なんか本題と関係ない方向に行ってしまった。

#perlcasual PerlCasual #06 行ってきた(だいぶ昔の話

だいぶ昔の話ですが、chiba.pm #5でこんなLTしてきました。Chiba.pm #5 : ATND今の会社ではこんな感じでログ収集していて、こんなログ監視してるけど、他のところではどんなことしてるの?的な発表でした。現状は各webサーバのアクセスログをfluentdで収集して、ログサーバでファイルに吐かれたログを解析して、vhost,path,status(401,404,500)毎に閾値が以上のアクセスが来ているモノに関してアラートを上げるようにしてます。スクリプトでログ解析していたものが、Aggregationsでだいぶ楽に出来そうな目処が出来てる感じです。この辺別の機会にエントリ書きたいです。ともあれ、このくらいの規模の勉強会が個人的には楽しいです。次回も参加したいです。