しているというエニグモのようなイケてるウェブ企業としてはあるまじき状態が続いていました。系かつオンプレミスサーバーで動いていたこともあり色々と問題を抱えていました。移行することにしました。チャンネルがありましたが、失敗しているのが当たり前になってしまっていたため誰も気にしておらず、失敗通知が虚しく響き渡っていました。実行結果が違う問題について。化はされていませんでした。上でも同じイメージを利用する方針としました。いうツールを利用します。いう方式があり、それ専用のイメージも用意されているのでそちらを採用しました。マージして初めてテスト結果がわかるという状態でした。この場合マージした後に失敗したことに気づき修正する、という流れになりますが、テスト時間が長いこともあり失敗していることに気づかず放置されてしまいます。マージする前にテストを実行する、という当たり前のことが出来ていない状態だったのです。このように記述するだけです。merge_requests問題はリソースです。ジョブがトリガーされた場合リソースが足りなくなってしまう懸念がありました。こちらの記事が参考になります。移行後の構成この構成の設計や移行作業は全て弊社インフラエンジニアである夏目さんによるものです。ありがとうございました!!実行速度を速くしたい!さて、ブランチごとに実行する環境は整いました。全てのテストが完了するまで2時間ほどかかってしまうという最大の問題が解決されていません。時間は流石に待ってられません。速くする方法としては、テストコード内で無駄にレコードを作らないなど色々プラクティスがあると思いますが、数百ファイルのテストファイルを全て見て修正するというのは現実的ではありませんでした。並列化という方法で解決することを考えました。コマンドではなくそれぞれのテストファイルを独立して実行するスクリプトを利用していました。全てのスペックファイルを単独で実行するためのスクリプト。オプションを利用して並列化を実現しました。フィールドを追加します。個のジョブを並列で実行することにしました。いう環境変数がセットされます。つの環境変数から実行するファイルを算出します。並列化後のスクリプトはこちらです。全てのスペックファイルを単独で実行するためのスクリプト。倍速くなるというわけにはいきませんでした。これ以上並列数を増やしても速くなることもありませんでした。脱却することができました。落ちて放置されているというような状態に精神が乱されるタイプなので心の平穏を取り戻すことができました。上記の作業をする前に落ちまくって放置されているテストを全て直すという作業があったのですが正直そこが一番きつかったです。ツールはじめにみなさん、こんにちは。BUYMAの検索周り、時々機械学習なエンジニアの伊藤です。今年もあっという間の1年でしたね。振り返ってみると多くのことを学ばせてもらい、また成長させてもらった1年でした。その中でもk8sがやはり自分の中では中心だった気がします。今回はk8sネタで今年を締めくくりたいと思います。k9sとは?k9sとはk8s上のリソースを監視、管理するためのCLIツールです。k8sのCLIといえばkubectlがデファクトですが、そのI/Fをよりリッチに使いやすくしたのがこのツールです。canine=犬のヌメロニム表記であるk9と、kubernetesのk8sが表記的に近いから犬なんだなと勝手に納得することにしました。使ってみるでは実際にk9sをインストールして使ってみましょう。Linux、OSX、Windows上で動作するようですが、今回はMac上でインストールして動かしてみたいと思います。枠内にpodの一覧など、指定した情報が表示されるようになっています。podで取得できる項目相当の一覧が見れますが、CPU、メモリ使用率なども表示されます。基本操作について基本的なところさえ抑えておけば、あとは直感的に操作が可能です。コマンドモード:でコマンドモードになります。続けて、k8sのリソース名(alias名でも可)を指定することでその一覧が表示されます。指定するリソース名を忘れた場合はCtrl-aで確認できます。deploymentの一覧を確認したい場合は:dpと入力してEnterでdeploymentの一覧が表示できます。Escでコマンドモードを抜けます。フィルター/のあとにフィルターを指定することで絞り込みが可能です。任意の文字列だけ入力してもその文字列がpod名やnode名に含まれれば絞り込みが可能です。Escでフィルターを解除します。ソートShiftと特定のキーで項目毎のソートが可能です各項目とキーのマッピングは?で確認できます。昇順/降順の切り替えはShift-iで行います。実践的な使いどころ基本操作が分かったところで、よりk9sの便利さが伝わるように下記のような場面を想定した操作をしてみます。k9sの使い始めは慣れない分、「そこまで便利か?」っていう感じを受けるかもしれません。自分は最終的にどちらかに移行するというよりは、下記のような使い分けをすることで落ちついています。単発の確認はkubectl例えば今のpod一覧を知りたい時など、特定の情報だけ知りたい場合はわざわざk9sを起動する方が手間なので、kubectlだけで済ませています。解析作業や複数のコンテキストを跨る作業こういう場合は圧倒的にk9sが便利です。上でも記載していますが、クラスタ側に何か異常があった場合には、様々なリソースの情報を見ていくことになると思います。コマンドを打つことなく少ないキー操作で確認が可能です。複数のkubectlコンテキスト内のリソースを同時にみるのはkubectlではできませんが、k9sでは別ターミナルで起動してコンテキストを切り替えることで、ターミナルの切り替えだけで複数コンテキストの操作や参照が可能になります。最後にk8sとその周辺エコシステムは進化が激しく、日々新しい機能やツールが出てきている印象です。キャッチアップが大変ですが、今後も日々の運用やシステムの安定性に繋がるようなものは時間を見つけて試していきたいと思います。組織こんにちは、サービスエンジニアリング本部の穴澤です。今年の1月に入社して丁度1年になります。良いタイミングなので1年を振り返ってみたいと思います。これから転職をしてみようかなと考えている人、新しい事に挑戦したいと思っている人に読んでもらえると幸いです。前日は眠れませんでした。6年働いた前職から転職し、人間関係はゼロから。使っている技術、サービスも違う。大丈夫かなー3ヶ月後生きてるかな?と思っていました。入社後は環境構築しつつ、その後運用業務を上司から少しずつ分けてもらい日々の業務全体をみるようになりました。エンジニアとしての経験を買ってもらって入社したものの、プログラミング言語での経験は主にPHPだったのでエニグモでのRailsを使った開発に戸惑うところも未だにあります。このタイミングでチームに新しく入ってきた方も居たので受け入れ時に必要な情報やドキュメントを徐々にまとめて自分がサービスの説明や開発フローを説明できるものを準備しました。この頃はまだ前職の人たちとの飲み会が多く、ホームシック的?な気持ちになったのを覚えています。ああ、転職したんだなあ、という気持ちでした。EM見習いとして入社したので、入社したその月からメンバーの方と一人ひとり話をする時間を持ち始めました。みんながなにやってるのかわからん。「社内での情報共有サービスを移行しよう」という動きがありチームを横断した形でエンジニア数名、関係者含めて小さいチームが発足しました。私自身が刷新に前向きだったのでやってみようと思い手をあげることになりました。おんぶにだっこでした。このチームのおかげで普段接点のない部署の方々とお話する機会があったかなと思います。名前もだいぶ覚えてきました。夏場に大きな施策が控えており、メンテナンスが必要になったため自分が担当になりました。過去メンテのドキュメントを探しマニュアルや手順書の整備をはじめました。メンテにはインフラエンジニアや他のサーバサイドエンジニアの方もいましたが「入社して半年でメンテ要員わたしで大丈夫かな?」と思いながらテスト環境で手順書の確認やわからないことを少しずつ潰していきました。7-9月サーバーメンテナンスは深夜に実行する事となり、夜に関係者が出社しメンテナンスを終えたのは朝でした。そのまま朦朧としたまま会社を出、ファストフード店でおいしい朝ビールをいただきました!色々と学びが多い月でした。メンテをしたことでちょっとシステムの全体構成やアーキテクチャ全般が「わかった気」になったのを覚えています。開発業務で機能をゴリゴリ書いている身ではないので案件の調整や小さい運用、リリースの調整やドキュメントの整備、問い合わせやMTG、ちょっとした相談・・・。いう事に忙殺されているとたまに「わたしエンジニアって言っていいんだっけ?」と悲観的になることもあるのです。なんだか何もしてないな、EMで入ってきてるけどわたし大丈夫かな。不安になったこともありました。チームの成果を伸ばしたい、組織に貢献したい。技術力そのものだけじゃないところで活躍したい。自分の達成チケット数=成果ではないという事を上司に確認したこともありました。その際、「そういう前提であなたを迎えているのですから(大丈夫ですよ)」と言ってくれたのはいまでも覚えています。メンテも経験したことで、この辺りからはっきりと自分の役割を理解してきました。技術的な学習や実際の開発から完全に手をひいたわけではないけれどそこに自分の価値があるわけではない。いうのが1年たった気持ちです。10-12月リリースに関わる改善をしたいと日頃思っていたので、夏過ぎからまた有志のチームで細々と情報の整理と改善の策を練るところからはじめています。不安ですが自分にできることを探していこうと思います。春先から頑張ってきた採用活動が実を結び、新しい人が入社してくれました!人材育成も過去の経験をそこそこに活かしながら、今わたしの目の前にいる人の顔をみて、自分ができる「お手伝いをしていこう」と思った今日このごろです。最後に異なる環境に飛び込むことは色々考える事も多いし悩みも多いです。それでも今年楽しかったな、ここはやりきったな。いう達成感はあります。それと、自分がどんどん自社のサービス・支える人を好きになってると感じます。携われる領域やできることが些細なことでも一つふえると嬉しいものです。環境や周りの人を強制的に変えることで視野が広まったり自分が少しずつ変わる変化を、来年も楽しんでいこうと思います。弊社エンジニアの木村が登壇しました。活用した事例についてお話ししました。発表資料を公開します。はじめ、それに伴ったデータ収集・分析・活用のインフラとしてGCPやAWSを活用しています。モデルの運用、サービスへの組み込みなど大規模データを扱ってみたいエンジニアを募集しています。実装するこんにちは、エンジニアの齊藤です。ついて書きたいと思います。ついてユーザー向けのウェブアプリケーションの実装で必ずといって発生するのが、インプット値のバリデーション処理です。ファイルのコンテンツ等そのケースは様々です。バリデーションを実装するのが一般的ですが、モデルのアトリビュートを逸脱したこのようなケースではそれぞれ専用のクラスを実装する必要があります。いう記事のなかで紹介された設計テクニックの一つです。使って実装しています。アトリビュートを定義して、通常のモデル同様にバリデーションルールを実装します。インスタンスと差異がないので、バリデーション専用のモデルを実装しているのと同じです。@messages={:product_name=>["を入力してください。気になっていたのですが、全く違う設計のライブラリのため導入までにはいたりませんでした。リリースされたのをきっかけにこちらに乗り換えてみることにしました。記述がわかりやすく、ドメインロジックのバリデーションルールと明確に処理を分離できる点だと思います。実装方法について説明していきます。自体の共通の設定はベースクラスを用意して定義します。エラーメッセージの出力時のロケールの設定、共通ルールのマクロやカスタムデータタイプをここで定義します。強制する文字列のハンドリングのために利用するデータタイプです。定義してバリデーションします。パラメーター向けのスキーマ定義のメソッドです。