Cybozu Inside Out | サイボウズエンジニアのブログ

 

フロントエンドカンファレンス福岡 2019 に行ってきました

こんにちは、フロントエンドエキスパートチームです。

先日、11/16(土)に福岡の九州産業大学で行われたフロントエンドカンファレンス福岡 2019 にシルバースポンサーとして協賛しました。チームから@toshi-toma@__sakito__が登壇し、当日はチームで参加したので、その時の様子をお伝えしたいと思います。

https://frontend-conf.fukuoka.jp/

登壇について

まず、登壇した@toshi-toma@__sakito__の登壇内容について、紹介します。

@sakito

セッション概要

speakerdeck.com

なぜテストを書くのかという説明。テストの開発コストと速度のバランスを考えて、testing trophy で提唱されている Static,Unit,Integration,End to End,の 4 層の解説。

React,React Hooks のテストについてどのようにテストを書いていくのかという話をしました。

@toshi-toma

セッション概要

speakerdeck.com

フロントエンドエキスパートチームとして複数のプロダクトに関わった経験を活かし、これまでのフロントエンドの遍歴について話すことで、いまのフロントエンドがどのような状態なのかについて話しました。内容としては、UI ライブラリ、モジュール、AST と周辺ツールについて深ぼって話しました。

各メンバーの感想

次に、参加したメンバーの感想を一言ずつ紹介します。

  • @koba04
    • 昨年以上の盛り上がりを感じました。これからも福岡盛り上げていきたいと思いました!
  • @__sakito__
    • 去年も参加させて頂いていましたが、ノベルティ、会場 はもちろん細かい部分のクオリティがとても高くなっており、スタッフの方の福岡を盛り上げようという気持ちを感じました!
  • @shisama_
    • 福岡の盛り上がりを感じられてよかったです。セッションのカテゴリーも多く、様々な学びがありました。多くの方にブースに足を運んでいただき嬉しかったです。
  • @zaki___yama
    • 「新しい視点を見つけよう」というテーマにふさわしいセッションが聞けて、良い刺激になりました!
  • @toshi-toma
    • 初めての参加でしたが、福岡のエンジニアの方とたくさん交流できて楽しかったです。規模も大きく、面白いセッションが多かったです。
  • @pirosikick
    • セッションも充実していましたし、挽きたてのコーヒーやおしゃれなノベルティなど、昨年よりもさらにパワーアップしており、感動しました。

運営のみなさま、本当にお疲れさまでした。素敵なカンファレンスをありがとうございました!

スポンサーとして

最後に、今回スポンサーとして、配布物を作成し、ブースを出しましたので、そちらについても少しご紹介させてください。

配布物

チームで毎週火曜日に「フロントエンドランチ」という会を開いており、その週に各メンバーが気になった Web フロントエンドに関する記事・動画などを紹介したり、その週のjser.infoを眺めながらあーだこーだ言っています。

今回、カンファレンスで配布した印刷物には、その会で紹介した記事の中で各メンバーが印象に残ったものをピックアップして載せました。

FECF2019で配布したチラシ
FECF2019で配布したチラシ

ブース

サイボウズのブースでは、製品のパンフレットやノベルティの配布だけではなく、大きめのディスプレイを置いてモブプログラミングのデモを行いました。

サイボウズではモブプログラミングを取り入れているチームが多くあり、我々フロントエンドエキスパートチームも同様にモブプログラミングで日々のタスクを消化しています。実はこのブログもモブプログラミングで意見を出し合いながら書き上げました。

また、東京・大阪・松山・福岡と 4 拠点にメンバーが居るので、Zoom を使ってのリモートでモブプログラミングを行っています。ブースでは、我々が管理している npm パッケージの TSLint から ESLint に移行するモブを実施しました。

カンファレンス中に移行が完了し、npm publish も行えました!

今回のカンファレンスのテーマは「新しい視点を見つけよう」でしたが、まだ浸透していないモブプログラミングをデモすることでそのテーマに少しでも貢献できていたら幸いです。みなさんもぜひ、モブプログラミングやりましょう!

当日までの準備風景

弊社にはコネクト支援チームというエンジニアの対外的な活動を支えてくれるチームがあります。

カンファレンスの準備は、当然ながら業務中に行なっており、私たちフロントエンドエキスパートチームだけでは準備の時間が足りず、クオリティの担保ができませんでした。

そこでコネクト支援チームの方に協力していただき、ブース準備、配布物、当日の荷物の発送までたくさんお世話になりました。 自分たちがやりたいことができたのもコネクト支援チームのおかげです!!!!

コネクト支援チームが華麗に進めていく様子
コネクト支援チームが華麗に進めていく様子
コネクト支援チームのhokatomo作のセッション間のCM素材
セッション間のCMもhokatomo作
Twitterアイコンの缶バッチ
名刺代わりにTwitterアイコン缶バッチを作ってもらいました

We Are Hiring!!

フロントエンドエキスパートチームでは採用中です。東京・大阪・松山・福岡の 4 拠点にメンバーが居ますので、働く場所はどこでも OK です。 福岡はエンジニアが穴井だけなので、特に絶賛募集中です。

詳しい採用情報はこちら

 

Argo CDによる継続的デリバリーのベストプラクティスとその実装

こんにちは。Necoの池添(@zoetro)です。 現在San Diegoで開催されているKubeCon 2019に参加しているのですが、時差ボケで寝付けないのでこんなブログを書いています。

さて、現在我々はKubernetes上のアプリケーションの継続的デリバリーを実現するためにArgo CDというツールを利用しています。

github.com

本記事ではArgo CDについて簡単に解説した後、継続的デリバリーのベストプラクティスと具体的な実践例を紹介したいと思います。

Argo CD とは

Kubernetes向けの継続的デリバリーツールとしては、SpinnakerJenkins Xなどが有名です。 これらのツールは継続的デリバリーのパイプラインを統合的に管理・実行するためのツールになっています。

一方のArgo CDは、パイプライン全体を管理するのではなくパイプラインの中の1つの処理として動くコンポーネントになります。 このようなツールは継続的デリバリーコンポーネントと呼ばれることもあります。

今年の3月には、SpinnakerやJenkinsなどのプロジェクトを対象にContinuous Delivery Foundationが発足しました。 一方のArgo CDを開発しているIntuite社は、競合プロダクトであるFluxを開発しているWeave Works社と協力して、GitOpsの継続的デリバリーツールを開発していくようです。

www.intuit.com

これからの継続的デリバリーツール界隈は面白くなっていきそうですね。

さて、Argo CDの仕組みを簡単に解説したいと思います。

Argo CD continuous deployments
Introducing Argo CD — Declarative Continuous Delivery for Kubernetesより引用

図に示すように、開発者がアプリケーションのコードをGitリポジトリにPushすると、CIによってビルドされ、 コンテナイメージがコンテナリポジトリに登録されます。 そしてアプリケーションをデプロイするための設定(マニフェスト)をGitリポジトリにPushすると、 Argo CDはそのマニフェストをKubernetesクラスタに適用します。

このようにGitリポジトリに登録されている設定に基づいてデプロイする手法を GitOpsと呼びます。

Best Practices

先日、Argo CDのブログにて、5 GitOps Practicesという記事が公開されました。

この記事では以下の5つの項目をGitOpsのベストプラクティスとして紹介しています。詳細については上記の記事をご覧ください。

  1. Two Repos: One For App Source Code, Another For Manifests
  2. Choose The Right Number Of Deployment Config Repos
  3. Test Your Manifests Before You Commit
  4. Git Manifests Should Not Change Due To External Changes
  5. Plan How You’ll Manage Secrets

NecoプロジェクトではGitOpsによる継続的デリバリーの方法を試行錯誤していたのですが、 幸いにもこれらのプラクティスをすべて実践していました。

ここでは、我々がこれらのプラクティスをどのように実装しているのかを具体的に説明していきたいと思います。

1. Two Repos: One For App Source Code, Another For Manifests

1つ目は、アプリケーションのソースコードのリポジトリと、マニフェストを管理するリポジトリを分離せよというプラクティスです。

Necoプロジェクトでは、マニフェストをneco-appsというリポジトリで管理し、 アプリケーションのソースコードはそれぞれのアプリケーションのリポジトリで管理しています。

neco-apps

Argo CDはHelmやKustomizeなど、いくつかのマニフェストレンダリングツールに対応しています。 neco-appsでは環境ごとの差分管理や、後述するOff-the-Shelf Configurationの利用のしやすさを考慮して、 Kustomizeを採用しています。

また、Gitブランチを利用して環境ごとの適用戦略を定めています。

masterブランチに適用されたマニフェストは、毎晩テストが実行されstageブランチにマージされます。 stageブランチにマージされたマニフェストは、Argo CDによりステージング環境に自動的にデプロイされます。

ステージング環境でしばらくの間、問題なく動作することが確認できたら、手動でstageブランチをreleaseブランチにマージします。 releaseブランチにマージされたマニフェストは、Argo CDにより本番環境に自動的にデプロイされます。

このような戦略により、各環境への継続的デリバリーが実現できています。

2. Choose The Right Number Of Deployment Config Repos

2つ目はマニフェストを管理するリポジトリの数を適切に選ぶというプラクティスです。

サイボウズではKubernetesクラスタの構築と運用をおこなっているNecoプロジェクトのメンバーと、 アプリケーションを開発しKubernetesクラスタ上で運用するメンバーでチームがわかれます。

これらのチームごとにマニフェストを管理するリポジトリを用意しています。

また、Argo CDにはProjectという、 アプリケーションのデプロイ設定をグルーピングして管理する仕組みがあります。

Projectでは、利用可能なリポジトリやデプロイ先のKubernetesクラスタやnamespaceを制限することが可能です。 開発チームは特定のnamespaceにしかアプリケーションをデプロイできないように制限しています。

このようにマニフェストのリポジトリを分離しProjectの機能を活用することで、 各チームは他のチームに影響されることなく、自分たちのタイミングで自由にデプロイをおこなうことが可能になっています。

3. Test Your Manifests Before You Commit

3番目はコミット前にマニフェストをテストせよというプラクティスです。

Necoプロジェクトでは、マニフェストのテストとして三段階のテストを用意しています。

1つはマニフェストのレンダリングを実行し、そのマニフェストのバリデーションをおこなうテストです。

2番目はkindを利用した簡易テストです。 マニフェストがKubernetesクラスタにデプロイできることや、デプロイしたソフトウェアの基本的な機能が利用できることを確認しています。

最後の1つは、以前紹介した仮想データセンター上でのテストです。 データセンターを模擬した仮想環境を利用して、本番とそっくりな環境でのテストが可能になっています。

この仮想データセンター上で、kindで実施している基本的なテストに加え、マニフェストのアップグレードテストもおこなっています。 アップグレードテストでは、現在ステージング環境や本番環境に適用されているマニフェストを用いて環境を構築し、 そこに最新のマニフェストにアップグレードして、環境が壊れないかどうかを確認しています。 これまでこのテストで数多くの不具合を検出することができており、非常に有用なテストであると感じています。

ただし、この仮想データセンターでのテストは実行に時間を要するため、基本的にはstageブランチにマージする前だけに 実行するようにしています。

4. Git Manifests Should Not Change Due To External Changes

4つ目は、外部の変化の影響を受けて、マニフェストが変わってしまわないようにするというプラクティスです。

Necoプロジェクトでは、自前アプリケーションだけでなく外部のOSSのアプリケーションについても、 DockerHubなどに登録されているコンテナイメージを利用せず、neco-containersという リポジトリで管理し、自前でビルドして利用しています。

コンテナをビルドする際には、latestタグは付与せず必ず固定のタグをつけるようにしています。 そして、マニフェストではこの固定タグを指定しています。

これにより、一度リリースされたneco-appsのマニフェストは、いつ利用しても必ず 同じコンテナイメージを指すことが保証できます。

5. Plan How You’ll Manage Secrets

最後は秘密情報を適切に管理せよというプラクティスです。

GitOpsにおける秘密情報管理の決定的な方法がまだなく、様々な手法が提案されている状況です。

我々はまず秘密情報を下記の2つに分類しました。

  1. 漏洩した場合にデータセンターに侵入されたり顧客情報の流出につながる可能性のある秘密情報
  2. 1.に該当しない秘密情報

1.に関してはGitリポジトリでの管理は諦めることにしました。 手動のオペレーションが発生してしまうのですが、そもそも1.に該当する秘密情報は数が少なく 変更することもほとんどないため、運用でそれほど困ることはありません。

一方、2.に関してはGitHubのプライベートリポジトリで暗号化せずに管理し、 Argo CDで自動的にデプロイするようにしています。

Deep Dive into Argo CD

ここからは「5 Best Practices」では紹介されていない、我々がおこなっているプラクティスを紹介したいと思います。

App of Apps Pattern

Argo CDでは、Gitリポジトリから取得してKubernetesにデプロイするマニフェストの単位をアプリケーションと呼びます。 このアプリケーション設定自体もKubernetesリソースであるため、Argo CDで管理することが可能です。

また、複数のアプリケーションを管理するアプリケーションを作ることを App of Apps Pattern と呼びます。

neco-appsでは、以下のようにApp of Apps Patternのマニフェストを用意しています。

App of Apps Patternでアプリケーションリソースを管理すると、Argo CDで管理するアプリケーションが増減したとしても、 Web UIやコマンドラインでArgo CDを操作する必要はなく、マニフェストを追加してGitにPushするだけですみます。

Self Management

Argo CDもKubernetes上で動作するアプリケーションの一つであるため、Argo CDでArgo CD自身を継続的デリバリーすることが可能です。

Self Managementにより、Argo CDの更新も他のアプリケーションと同様におこなえるようになります。

マニフェストの適用状況をモニタリングする

前述したようなテストを実施していたとしても、実際にKubernetesクラスタにデプロイしてみると失敗することがあります。

Argo CDではPrometheus形式のメトリクスを公開しており、アプリケーションのヘルス情報や同期の状態を監視することができます。

Necoプロジェクトでは、Argo CD自体が一定期間ダウンしている場合や、同期の成功や失敗した情報をSlackで通知するようにしています。

Off-the-Shelf Configuration

neco-appsには、自社開発のアプリのマニフェストだけではなく、 Prometheusやcert-manager、Contourなど数多くのOSSのマニフェストが含まれています。

このようなOSSのマニフェストは、GitHub上のファイルとして配置されているもの、 Helm Chartとして配布されているもの、ドキュメントの中に埋め込まれているものなど、 配布方法は様々です。

また、配布されているマニフェストがそのまま利用できることは稀であり、マニフェストになんらかの変更を加えてから、 自分たちのリポジトリに追加することになります。 このように他から持ってきたマニフェストを取り込んで利用することをOff-the-Shelf Configurationと呼びます。

しばらく運用していると、このようなマニフェストはアップストリームのバージョンアップに 追従することが大変手間だと分かってきました。 配布方式に応じて変更点を確認し、自分たちが加えた変更を考慮しつつマニフェストのアップデートをおこなうのは骨が折れます。

Kustomizeでは、既存のマニフェストに変更点をパッチとして適用することができます。 そこでOSSで配布されているマニフェストを変更せず、そのまま自分たちのリポジトリに取り込み、 変更点のみをパッチで管理する方式を模索しています。

この方式であれば、アップストリームでマニフェストが変更されたとしても、そのマニフェストをそのまま持ってきて 上書きしてしまえばアップデートは完了します。

まとめ

本記事では、Argo CDを利用したGitOpsの実践例を紹介しました。 我々が試行錯誤してたどり着いたプラクティスなので、ぜひ参考にしてみてください。

 

インタビュー:MySQLエキスパートのyoku0825さんに聞いてみた

こんにちは。コネクト支援チームの風穴(かざあな)です。

この度サイボウズでは、GMOメディア株式会社とコンサルティング業務委託契約を締結させていただき、MySQLエキスパートのyoku0825さんに、いろいろと相談に乗って頂けることになりました。

MySQLについて検索したことがあるエンジニアなら、yoku0825さんのブログ「日々の覚書」のお世話になったことがない人はいないでしょう。それぐらいポピュラーなブログで、日本語で読めるMySQLの技術情報を長年発信し続けているのがyoku0825さんです。

yoku0825さんが壇上でお話しされてる写真
yoku0825さん

ということで、Garoonプログラマの杉山くんと一緒に、yoku0825さんにお話を伺ってみました。

yoku0825さんのお仕事

──(風穴):普段、どんなお仕事をされてるのですか?

yoku0825さん(以下、敬称略):GMOメディアという、BtoC向けのWebサービスを作っている会社で、いろんなサービスのデータベースの部分だけを専門に担当するチームに所属しています。サービスによって使っている技術が異なっていたりするのですが、データベースとしてMySQLを使っているものは私が担当しています。

──:ということは、結構お忙しそうですね。

yoku0825:何事も起こらなければ、そうでもないんですけどね(笑)。「ALTER TABLEを叩いてください」とか、それぐらいだったらいいんですけど。

杉山:分かります(しみじみ)。

──そんなお忙しい中で、あのブログも書かれていて……。

yoku0825:そういえば私のブログに、たまにリファラがサイボウズからのアクセスが集中的に来ることがあるんですけど、さっき社内システム(編注:kintone)の使い方を見せてもらって分かりました。なるほど、こういう仕組みでアクセスしてくるのね。

杉山:そうなんです。社内勉強会なんかがあると、社内のkintoneにそれ用の実況スレッドが用意され、そこにみんなで実況ツイートみたいに書き込んでいくというのをよくやります。そこに参考資料としてブログ記事のURLが共有されると、みんなこぞってアクセスしちゃうんですよ。Twitterでも「サイボウズから狙われてるらしい」みたいに呟かれることがあります。

──GMOメディアに入社されてからは、どれぐらいになります?

yoku0825:この12月で7年になります。入社するときから、MySQL以外はやらないぞ、と決めてました。私を採用した人も「そうは言っても、目の前にあったらOracleの面倒も見てくれるだろう」と考えたと思うんですけど、ホントにまったくやらなくて。

──すごいですね。

yoku0825:「OracleのBronzeとか取らないの?」と言われても、「取りません!(キッパリ)」と(笑)。

──yoku0825さんの働き方ですが、毎日通勤されてます?

yoku0825:そうですね。最近は毎日通勤してますね。週のうち1日はサイボウズさん、もう1日は別の会社さんに行ってまして、そのときには会社にも立ち寄るようにしてます。もともとは週2日ぐらい自宅からリモートでやってたりしたのですが。

──お仕事自体は、リモートからでもできるんですよね?

yoku0825:はい、そうです。私がいじるモノはデータセンターにあるので、会社に行こうがどこにいようが、そもそもがリモートというか。

──確かに!(笑) ちなみに、yoku0825さんご自身は、働く場所を選びたいタイプですか? サイボウズはかなり自由な働き方ができるのですが、「自宅だと集中できない」「オフィスが良い」と言って通勤する人も結構います。

yoku0825:どちらかというと場所は選ばないほうですね。自宅でも大丈夫です。子どもが夏休みのときはちょっと厳しいですが。ドタン、バタン、アー、みたいな感じなので(笑)。

──ご自宅でもお仕事されてると、その姿をお子さんも見てるんですよね?

yoku0825:仕事で「MySQLをしてる」というのは知ってるみたいで、黒い画面で何かしてる……と思ってるようです。何かあると緊急対応することもあるので、家族と出かけたりするときでも常にPCは担いで行ってます。子どもが物心つく頃からずっとそうなので、仕事の携帯電話が鳴って「あ、ごめん、アラート」って言うと、みんなスーッと波が引くように離れていきます。

──すごい、よく訓練されてる!(笑)

yoku0825:ここから父親は構ってくれなくなる、ここから夫は手伝わなくなる、というのを学習しちゃってるみたいです。

──趣味とか、仕事以外で何かされてることってありますか?

yoku0825:基本的に昼寝は大好きです。もちろん自分の布団がいいんですけど、床でも寝ますし、寝っ転がれればどこでも(笑)。

出会いはTwitter

──サイボウズから声がかかったのは、どういう経緯で?

yoku0825ymmtさんからですね。

──それはTwitterのDMで?

yoku0825:そうです。

──お互いにフォローしてたんですね。

yoku0825:はい。ymmtさんは以前、新しめのDebianのGCCでMySQLをビルドするとセグメンテーション違反になるという、なかなか激しいバグを踏んでまして。私は最初、それをバグレポートで見たのですが、日本の人っぽいし、そのバグの件をツイートしてる人がいて、すごくコアなというかニッチなバグを踏み抜いてるし、その前後はGCCの話とかMySQLの話とかが続いてたので、面白そうな人だなぁと、ポチっとフォローしてたんです。

──なんと、そんな繋がりだったとは! その後、どこかで会ったりしてたんですか?

yoku0825:いえ、Twitterでメンションし合ったぐらいで、会ったことはなかったです。

──Twitter活動は大事ですね。それが巡り巡って、こんな形で一緒にお仕事できるようになるとは。素晴らしい。

杉山:Twitterすごい!

yoku0825:ホントに。

杉山:yoku0825さんに声をかけてみようとなったのも、Twitterじゃないんですけど社内SNS(編注:kintone)で、MySQLの強い人に相談したいみたいなことを書いたら、ymmtさんとか本部長とかがすぐに反応してくれて始まったので、それもちょっと似てますね。

──社内で呟いてからの展開が早かったですよね。サイボウズは、社内がフラットで話は早いほうだと思うけど、それでもこれはかなり早い展開で私もビックリしました。

yoku0825:そうなんですね。

──で、サイボウズでお願いすることは決まってる?

杉山:いや、具体的にはまだですね。いろいろお話を聞いて頂いて相談しているところです。

yoku0825:とりあえずガルーンを、1つずつでも今より良くしていくのをやりたいですね。

杉山:そうですね。ぜひ! いまはまだ何をどうするか相談しているフェーズなので、具体的に何からやっていくかは決まってませんが、とても楽しみでワクワクしてます。

MySQLエキスパートまでの道のり(長いよ)

yoku0825:実は昔、芝居のライティング、照明をやってまして。

──それは、劇団の舞台公演みたいなので?

yoku0825:そうです、そうです。それも、どこか特定の劇団に所属するんじゃなくて、あちこちでやってました。だいたい、裏方のスタッフって少ないので、インターネット掲示板で募集があるんですよ。「何月何日に本番、それまで月イチで稽古するので来られる人」みたいな感じで募集があるので、それを見て行ってました。そういうのをアルバイトみたいにしてやってたら、専門学校の出席日数が足りなくなり、ドロップアウトして、コンビニに勤め始める……と。

──えーっ、何ですかその波瀾万丈な展開は。

yoku0825:高校3年生のとき、クリスマスの前後の時期に昭和記念公園へ行ったらライトアップイベントをやっていまして、それがすごくキレイだったんですよ! その頃、すでに大学受験をする気満々だったんですが、それを見て家に帰ってすぐ父親に「ごめん、大学は受けずに照明の専門学校へ行っていい?」と言ってました(笑)。

──それまでは、そんなことをやりたいというのは微塵もなく?

yoku0825:はい。いま思うと「何で?」と自分でも思います。ライトアップは、確かにキレイなのはキレイでしたが。子どもが高校3年生のときに昭和記念公園(※1)に連れて行くのはやめたほうがいいかも(笑)。

──私も高1の息子がいるので、気をつけます(笑)。ちなみに、元々受験しようとしてた大学は、情報工学系だったんですか?

yoku0825:いえいえ、全然違います。化学をやりたかったので、そっち方面の大学でした。それも消極的な理由で、純粋な数学は好きじゃなかったんですよ。目に見えないから良く分からない(笑)。物理も苦手で。あと、父親も確か化学系だったんですよね。だから「化学やりたいな」とグーンと期待を上げたところで「ごめん、やっぱり……」だったので、2、3日は怒られましたね。

──お父さんのお気持ち、お察しします……。

yoku0825:結局、TV系列の専門学校で、アナウンサーや音響といった学部と並んで照明の学部があるところへ行きました。

──最終的には、本人の希望通りにさせてあげたお父さん、すごいですね。素晴らしい。

yoku0825:で、挙げ句の果てが、舞台照明のアルバイトに熱中しすぎて出席日数が足りなくなり……ですからね。そりゃ怒るよなぁ(笑)。いま思うと、ホントに悪いことをしたなと思います。

──お父さんに同情します……。結局、その専門学校は卒業せず?

yoku0825:はい、してないんです。フッフッフッ(笑)。

──えーと、すみません、これいつMySQLの話につながるんでしょうか? まだITに繋がる話が全然出てきてないんですが(笑)。

yoku0825:専門学校をやめたタイミングで、ちょうど話があってコンビニエンスストアの契約社員になったんです。副店長として。

──それは、元々アルバイトしていて声をかけられた?

yoku0825:そうです。社員募集があるから「受ける?」と言われて「受けます!」みたいな。

──えっ、というか、舞台照明のアルバイトが高じて専門学校をやめたのに、そちらの道には進まず、コンビニの副店長? どこまで予想外なんですか!

yoku0825:ええ、自分でも「どうしてそうなった?」感はあります(笑)。そのコンビニで、帳簿データをExcelに入力する仕事がありまして。そのとき、何かのはずみでマクロを使ってちょっとした自動化をやり始めてしまって、楽しくなっちゃったんですね。

杉山:お、やっとITの話が!

──MySQLエキスパートの原点が、まさかのExcelマクロにあったとは!(笑)

yoku0825:そこでFOR文、IF文、楽しい〜みたいな。で、そこに3年ぐらい勤めたんですが、そこでプログラミングをやりたくなってしまって、つい「未経験者歓迎」というフレーズに釣られて転職をすることになりました。

──「未経験者歓迎」は怪しい!(笑)

yoku0825:まさにそうでした。「プログラミングをやりたい!」と希望して実際に入ってみたら、プログラミングじゃなくて、単なるオペレーター業務でした。使ってたのはDECのAlphaワークステーションで、Tru64 UNIXとかでしたね。

──Alpha! Tru64! 懐かしい!

杉山:???

yoku0825:そこで、日々、マクロを書いてました。

──マクロ? m4?

yoku0825:いえ、TeraTermのマクロです!(笑) ターミナル側で、こういうプロンプト文字列が来たら、こういうコマンドを返す、みたいなのをたくさん作ってました。

──オペレーションを自動化してたんですね。

yoku0825:そうです。このホストに接続するには、踏み台としてこれを経由するとか、あとは、あのホストに接続するにはRASでダイヤルアップする必要があるけど、それには電話連絡で申請する必要があるので、それを「確認した?」というポップアップが出るようにしてたりとか。

──面白い! 面白いんですけど、まだまだMySQLには遠い気もするんですが……。

yoku0825:その後、その会社の保守窓口のチームで仕事をするようになり、そこはイントラネットで使っているシステムも担当してたんです。それは、Visual BasicとMS Access、それとIIS(※2)で作られてまして、MS Accessがボトルネックなので何とかしようと。もちろん予算はないので、そのときライセンスが余ってた「SQL Server 2000」か、PostgreSQL、そしてMySQLのどれにするかという話になって、「じゃあMySQLで」と。

──やっとMySQLにつながった!(笑)

yoku0825:これがMySQLとの最初の接点でした。

──お話を伺ってると、MySQLのほうを目指してきてたどり着いたというよりも、偶然というか、まったく関係ない選択をしてきたら、MySQLに出会っちゃった、みたいな感じですよね?

yoku0825:はい、まったくの偶然です。

──でも、もしかすると、PostgreSQLのほうに行ってた可能性もあったんですよね?

yoku0825:そうですね。ただ当時PostgreSQLにはレプリケーションがなくて、それを実現するためにはpgpool-IIを使って二重に書き込まないといけなかったのですが、当時pgpool-IIはWindowsで動かなかったんですよ。ということで、レプリケーションができるということでMySQLになりました。

──ExcelマクロやTeraTermマクロからの飛躍がすごいんですが(笑)、そういうのは全部、そのイントラネットの部署に来てから独学で?

yoku0825:そうですね。調べるのは苦じゃなかったし、英語は読めたというか、少なくともアレルギーはなかったので気にならなかったですね。英語では大量にドキュメントがあったので、それをひたすら読んだりしてましたね。

──いやぁ、すごいですね。まさか、昭和記念公園のライトアップがMySQLに繋がっているとは。

杉山:こんなキャリアもあるんだ……と衝撃を受けてます(笑)。

yoku0825:この会社には30歳直前まで勤めました。やってるうちにMySQLのほうが楽しくなって、これを専門にやろうと思って、MySQLの代理店をやっていた前職に転職し、そして7年前に今のGMOメディアに入社しました。

杉山:7年前というと……

yoku0825:MySQLが5.5.23の頃ですね。

──即答するし!(笑)

(了)

文責・写真:風穴 江(@windhole


※1昭和記念公園は、東京立川市、昭島市にある国営公園。180haもある広大な敷地に様々な施設が設置されています。

※2:「IIS」は、MicrosoftがWindows Server用に提供しているWebサーバ「Internet Information Services」の略。


【変更履歴】
2019年11月19日:「『日々の覚書』のお世話になったことがないひといないでしょう。」を「『日々の覚書』のお世話になったことがない人はいないでしょう。」に修正しました。

 

CKEがKubernetes Conformance Softwareに認定されました

こんにちは、Necoプロジェクトの池添(@zoetro)です。

このたびサイボウズがCNCF(Cloud Native Computing Foundation)にシルバーメンバーとして加盟しました。 それに伴い、我々の開発しているCKE(Cybozu Kubernetes Engine)がKubernetes Conformance Softwareに認定されました。

https://raw.githubusercontent.com/cncf/artwork/master/projects/kubernetes/certified-kubernetes/versionless/color/certified-kubernetes-color.png

CKEはKubernetesクラスタの構築と運用を自動化するためのソフトウェアです。 本記事ではCKEの概要と、他のツールとは異なる特徴的な機能について紹介したいと思います。

Kubernetes Conformance Softwareとは

Kubernetes Conformance Software ProgramとはCNCFが実施している認定プログラムです。

www.cncf.io

認定を取得するためには、Sonobuoyによる適合テストに合格する必要があり、 これによりソフトウェアがKubernetesの標準に適合していることを保証することができます。

認定済みのソフトウェアであれば標準的なKubernetesの機能が利用できるため、エンドユーザーは安心して利用することが可能になります。

CKEとは

github.com

CKEは下記のような特徴を持つKubernetesクラスタの構築と運用を自動化するためのソフトウェアです。

  • Declarative ConfigurationによるKubernetesクラスタの構築と運用の自動化
  • さまざまなKubernetesの機能に対応
  • いくつかのKubernetesリソースを標準でセットアップ
    • CoreDNS, Node-local DNSキャッシュ
    • RBACやPodSecurityPolicyなどマルチテナント運用に必要なポリシー
  • インプレイスでのKubernetesのアップグレード
  • コンテナランタイムとしてDockerとCRI Runtimeをサポート
  • 任意のKubernetesリソースの管理機能(CNIプラグインのセットアップなどに利用可能)
  • サーバー管理ツール(sabakan)との連携機能
  • バックエンドにetcdVaultを利用
  • CKE自体もHA構成で高可用運用可能

CKE Overview

CKEはDeclarative Configuration(宣言的設定)を採用しています。 Kubernetesクラスタのあるべき理想の状態を宣言しておくと、CKEは実際のKubernetesクラスタの状態が理想の状態に収束するように必要なオペレーションを自動的に実行します。

これにより、スクラッチからのKubernetesクラスタの立ち上げ、故障が発生したときの自動修復、各種ソフトウェアのアップグレード、ノードの追加や削除、各種設定の変更などがすべて自動的に実施されます。

我々のKubernetesクラスタでは1,000台規模のノードを取り扱うので、運用コスト的にこのような自動化は必須となってきます。

CKEの特徴的な機能

Kubernetesクラスタを構築するツールは数多く存在しますが、CKEはそれらとは異なる特徴的な機能を備えています。 本記事ではそのいくつかを紹介したいと思います。

なお、CloudNative Days Tokyo 2019においてCKEについて発表しました。興味のある方はぜひご覧ください。

speakerdeck.com

インプレイスでのKubernetesのアップグレード

Kubernetesクラスタ構築ツールにおいて、無停止でのKubernetesアップグレードは悩みのタネのひとつです。

例えばKubernetesの標準的なクラスタ構築ツールであるkubeadmでは、 kubectl drainコマンドでワークロード(Podなど)を別のノードに退避させてからアップグレードをおこないます*1

このような方式の場合、ノードのローカルストレージを利用しているようなステートフルなアプリケーションを退避させるのはコストが大きく難しい作業になります。

一方、CKEではワークロードの退避をせず、以下のようなインプレイス方式でのアップグレードをおこなっています。

  1. 新しいバージョンのKubernetesコンポーネント(kubeletなど)のコンテナイメージをノード上にロードする
  2. Kubernetesコンポーネントの設定ファイルを更新する
  3. 古いKubernetesコンポーネントを停止し、新しいKubernetesコンポーネントを立ち上げる

各種ワークロードはコンテナランタイム上で動いているので、Kubernetesコンポーネント(kubelet)を再起動しても問題なく動き続けることが可能になっています。

OSやコンテナランタイムを更新する場合にはkubeadmと同じ方式でアップグレードする必要がありますが、 Kubernetesのアップグレードだけであればこのような簡単な方法で高速に実施することができます。

サーバー管理ツール(sabakan)との連携機能

CKEでは理想のKubernetesクラスタの状態を宣言すると説明しました。 しかしノードが1,000台規模のクラスタでは、理想の状態を宣言するだけでも一苦労です。

例えば、以下のような様々な状況を考慮して動的にクラスタの理想状態を変更していく必要があります。

  • ハードウェア故障が発生したノードにPodがスケジューリングされないようにする
  • コントロールプレーンが同一ラックに配置されないようにする
  • 退役時期が近いノードよりも新しいノードを優先してクラスタに追加する
  • リソースが不足しているのでノードを追加する

Necoプロジェクトではsabakanというツールを開発して、サーバーのプロビジョニングや、サーバーのメタデータや健康状態の管理をおこなっています。

CKEはsabakanが提供する以下のような情報をもとに、クラスタの理想状態を自動的に更新します。

  • モニタリング情報
    • ネットワーク接続可能性
    • ハードウェアの故障状態
    • インストールされているOSのバージョン
  • 静的な情報
    • 退役までの期間
    • 搭載しているハードウェア
    • 配置されているラック番号

詳しいアルゴリズムを知りたい方は以下をごらんください。

まとめ

本記事では、Kubernetesクラスタの構築と運用を自動化するツールであるCKEの紹介をおこないました。

このような自動化をおこなったとしても運用コストがゼロになるということはなく、いくつかのオペレーションは人間が実施しなくてはなりません。 しかし、CKEのおかげでKubernetesクラスタの運用コストを大幅に削減することが可能になりました。

Docker-ComposeでCKEを立ち上げ、Vagrantで用意したVM上にKubernetesクラスタを構築するサンプルを以下に用意しました。 興味のある方はぜひ試してみてください。

 

JTF翻訳祭2019で発表しました

こんにちは。開発部テクニカルコミュニケーションチームの澤井です。 最近はまっているスイーツは、大丸東京店1階で売っているずんだシェイクです。

10月24日、第29回JTF翻訳祭に参加しました。テクニカルコミュニケーションチームから仲田と中島が「アジャイル時代の翻訳プロセス」というタイトルで発表しました。
この記事ではサイボウズの発表内容や、発表後にいただいた質問への回答などを紹介します。

JTF翻訳祭とは?

JTF翻訳祭は、一般社団法人日本翻訳連盟(JTF)が主催するイベントです。翻訳会社、翻訳者、クライアント企業などが数多く参加します。 セッションの内容は、機械翻訳の使用の最新事例や特定の翻訳分野のトレンド紹介、欧米の翻訳テクノロジーの紹介など多岐にわたっています。

サイボウズのセッション「アジャイル時代の翻訳プロセス」

朝一番のセッションでしたが、ありがたいことに100名ほどの方にご参加いただきました。また発表後の質疑応答タイムにはたくさんの質問をいただきました。

発表内容

この発表では主に以下の4つの内容についてお話ししました。

  1. プロダクト開発のアジャイル化に伴い、ドキュメント制作や翻訳プロセスはどう変化したか
  2. 高速なドキュメント更新を支える制作基盤について
  3. UI・ドキュメントの翻訳プロセスや使用しているツールについて
  4. 大規模ヘルプサイトの翻訳に機械翻訳を使用した事例の紹介

発表資料はこちらです。

www.slideshare.net ※公開ポリシーの都合上、当日の投影資料にあったツール類のスクリーンショットは除いています。

参加者からの質問

いただいた質問の中からいくつかご紹介します。

クライアント企業の方からの質問

機械翻訳のポストエディットを翻訳会社に依頼して行ったとのことだが、品質に不一致が出たのでは?関係者とどのように合意していますか?

サイボウズでは、ユーザーに素早く、最新のドキュメントの翻訳を届けることを重視し、Garoon 5のヘルプを機械翻訳を使って英語、中国語に翻訳しました。機械翻訳とポストエディット(機械翻訳の出力結果を人手で修正、改善すること。以下、PE)作業による翻訳版ヘルプの公開は今回が初でした。
(ちなみに、この作業では以前の記事で紹介した翻訳支援ツールが活躍しています)。
このプロジェクトでは、以下の要素が必須だったように思います。

  • 社内関係者と事前に利用目的と品質基準について認識を合わせる
    機械翻訳とPEを採用した最大の目的は「ユーザーに素早く、最新のドキュメントの翻訳を届けること」です。言い換えれば、スピードを重視しつつ訳文の品質について最大限の努力をする、ということになります。プロジェクトの開始時に、ヘルプ担当者、マーケ部の担当者などの関係者を交え、事前にこの目的について認識を合わせました。そしてPE後でも残ってしまう可能性のある誤訳については免責事項(PDF)で注意喚起しつつ、公開後も閲覧数などを確認しながら継続的に人間の手による翻訳で修正する方針としました。

  • 翻訳会社と品質基準の認識を合わせる
    機械翻訳のPEでは、訳文の品質にばらつきが出てしまう可能性があります。この点については、諦めても良い(PEしなくてもよい)ポイントを翻訳会社に伝え、納品物の品質基準について認識を合わせました。具体的には「用語の統一は諦める」「明らかにひどい誤訳からPEする」などです。

翻訳祭では、機械翻訳は翻訳者の仕事を奪うのではと言及されていました。また、PEの仕事を受ける翻訳者が少ない現状もあるようです。 一方で、機械翻訳は、人間には到底不可能な素早い翻訳スピードを実現し、今後ますます増えていく多くの情報を素早く世界中のユーザーに届けるためには欠かせない技術でもあります。今回のGaroon5ヘルプの翻訳も、分量の多さや翻訳期間の短さから、機械翻訳の活用が必要なプロジェクトでした。 アジャイル開発では、ヘルプなどのコンテンツも継続的に改善していくことが重要になります。サイボウズでは、翻訳手段のひとつとして機械翻訳も活用しながら、各言語のコンテンツを継続的に改善していきたいと考えています。機械翻訳+PEを採用したドキュメントの公開後も、必要に応じて人間の翻訳者による質の高い翻訳に置き換え、品質の向上を図ります。

翻訳者からの質問

翻訳者が社内翻訳者として働く場合と、翻訳会社から仕事をもらう場合とでは、必要なスキルセットはどう変わりますか?

別のセッションで話されていたことですが、翻訳会社での対IT企業の売り上げは、減少傾向にあるそうです。しかしこれは翻訳需要が減っているのではなく、企業が現場のニーズに即応した翻訳を行うために、翻訳を内製化しているためではないか、とのことでした。サイボウズもまさに翻訳需要の増加から、社内翻訳者を募集しています。翻訳者の方々もこの流れを感じ、キャリアチェンジを検討される方が増えているのではないかと感じました。 ご質問には仲田が「社内翻訳者には多様なコミュニケーションが求められる」とお答えしました。

社内翻訳者の場合、翻訳会社PMの役割の人物がいない場合があるため、翻訳をリクエストしている部署と主体的にコミュニケーションした上で適切な訳文を作成いただける方を求めています。また、サイボウズが提供するサービスやこれまで経験のないツール(GitHubなど)を覚えていただく必要があるので、新しいことを覚えるのが好きな方に向いています。このほか、その方の適性によって、機械翻訳の評価、翻訳関連で使用するツールの選定、社員の英語力向上への貢献など、力を発揮していただきたい場面がたくさんあります(通訳は今のところ募集していませんが、通訳経験のある方も歓迎します!)。興味を持っていただけた方は、ぜひご応募ください。

日英翻訳担当(技術文書・UI翻訳)
日英/英日翻訳担当(全般)

参加の感想

発表後、特にクライアント企業の方から多く質問をいただきました。原文の校正や更新差分管理、機械翻訳、翻訳関連ツールなど、関心領域はほぼ一致していて「御社ではどうされていますか?」とお聞きしたい気持ちになる場面もありました。質疑応答の時間以外で交流があまり持てなかったのが残念ですが、今後も継続的に参加して、情報収集や、機会をいただければサイボウズの取り組みについて発信していきたいと思います。